<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/include/linux/kvm.h, branch v3.5.3</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>KVM: s390: add capability indicating COW support</title>
<updated>2012-05-18T00:06:01+00:00</updated>
<author>
<name>Christian Borntraeger</name>
<email>borntraeger@de.ibm.com</email>
</author>
<published>2012-05-15T12:15:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1526bf9ccf310f1d35c1275b8b477a249d25aaf2'/>
<id>1526bf9ccf310f1d35c1275b8b477a249d25aaf2</id>
<content type='text'>
Currently qemu/kvm on s390 uses a guest mapping that does not
allow the guest backing page table to be write-protected to
support older systems. On those older systems a host write
protection fault will be delivered to the guest.

Newer systems allow to write-protect the guest backing memory
and let the fault be delivered to the host, thus allowing COW.

Use a capability bit to tell qemu if that is possible.

Signed-off-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Acked-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently qemu/kvm on s390 uses a guest mapping that does not
allow the guest backing page table to be write-protected to
support older systems. On those older systems a host write
protection fault will be delivered to the guest.

Newer systems allow to write-protect the guest backing memory
and let the fault be delivered to the host, thus allowing COW.

Use a capability bit to tell qemu if that is possible.

Signed-off-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Acked-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>kvm/powerpc: Add new ioctl to retreive server MMU infos</title>
<updated>2012-05-06T14:19:12+00:00</updated>
<author>
<name>Benjamin Herrenschmidt</name>
<email>benh@kernel.crashing.org</email>
</author>
<published>2012-04-26T19:43:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5b74716ebab10e7bce960d148fe6d8f6920451e5'/>
<id>5b74716ebab10e7bce960d148fe6d8f6920451e5</id>
<content type='text'>
This is necessary for qemu to be able to pass the right information
to the guest, such as the supported page sizes and corresponding
encodings in the SLB and hash table, which can vary depending
on the processor type, the type of KVM used (PR vs HV) and the
version of KVM

Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
[agraf: fix compilation on hv, adjust for newer ioctl numbers]
Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is necessary for qemu to be able to pass the right information
to the guest, such as the supported page sizes and corresponding
encodings in the SLB and hash table, which can vary depending
on the processor type, the type of KVM used (PR vs HV) and the
version of KVM

Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
[agraf: fix compilation on hv, adjust for newer ioctl numbers]
Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>KVM: Introduce direct MSI message injection for in-kernel irqchips</title>
<updated>2012-04-24T12:59:47+00:00</updated>
<author>
<name>Jan Kiszka</name>
<email>jan.kiszka@siemens.com</email>
</author>
<published>2012-03-29T19:14:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=07975ad3b30579ca27d880491ad992326b930c63'/>
<id>07975ad3b30579ca27d880491ad992326b930c63</id>
<content type='text'>
Currently, MSI messages can only be injected to in-kernel irqchips by
defining a corresponding IRQ route for each message. This is not only
unhandy if the MSI messages are generated "on the fly" by user space,
IRQ routes are a limited resource that user space has to manage
carefully.

By providing a direct injection path, we can both avoid using up limited
resources and simplify the necessary steps for user land.

Signed-off-by: Jan Kiszka &lt;jan.kiszka@siemens.com&gt;
Signed-off-by: Avi Kivity &lt;avi@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently, MSI messages can only be injected to in-kernel irqchips by
defining a corresponding IRQ route for each message. This is not only
unhandy if the MSI messages are generated "on the fly" by user space,
IRQ routes are a limited resource that user space has to manage
carefully.

By providing a direct injection path, we can both avoid using up limited
resources and simplify the necessary steps for user land.

Signed-off-by: Jan Kiszka &lt;jan.kiszka@siemens.com&gt;
Signed-off-by: Avi Kivity &lt;avi@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>KVM: x86: Add ioctl for KVM_KVMCLOCK_CTRL</title>
<updated>2012-04-08T09:49:01+00:00</updated>
<author>
<name>Eric B Munson</name>
<email>emunson@mgebm.net</email>
</author>
<published>2012-03-10T19:37:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1c0b28c2a46d98cd258d96b8c222144b22876c46'/>
<id>1c0b28c2a46d98cd258d96b8c222144b22876c46</id>
<content type='text'>
Now that we have a flag that will tell the guest it was suspended, create an
interface for that communication using a KVM ioctl.

Signed-off-by: Eric B Munson &lt;emunson@mgebm.net&gt;
Signed-off-by: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
Signed-off-by: Avi Kivity &lt;avi@redhat.com&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Now that we have a flag that will tell the guest it was suspended, create an
interface for that communication using a KVM ioctl.

Signed-off-by: Eric B Munson &lt;emunson@mgebm.net&gt;
Signed-off-by: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
Signed-off-by: Avi Kivity &lt;avi@redhat.com&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>KVM: Allow host IRQ sharing for assigned PCI 2.3 devices</title>
<updated>2012-03-08T12:11:36+00:00</updated>
<author>
<name>Jan Kiszka</name>
<email>jan.kiszka@siemens.com</email>
</author>
<published>2012-02-28T13:19:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=07700a94b00a4fcbbfb07d1b72dc112a0e036735'/>
<id>07700a94b00a4fcbbfb07d1b72dc112a0e036735</id>
<content type='text'>
PCI 2.3 allows to generically disable IRQ sources at device level. This
enables us to share legacy IRQs of such devices with other host devices
when passing them to a guest.

The new IRQ sharing feature introduced here is optional, user space has
to request it explicitly. Moreover, user space can inform us about its
view of PCI_COMMAND_INTX_DISABLE so that we can avoid unmasking the
interrupt and signaling it if the guest masked it via the virtualized
PCI config space.

Signed-off-by: Jan Kiszka &lt;jan.kiszka@siemens.com&gt;
Acked-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Acked-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Avi Kivity &lt;avi@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
PCI 2.3 allows to generically disable IRQ sources at device level. This
enables us to share legacy IRQs of such devices with other host devices
when passing them to a guest.

The new IRQ sharing feature introduced here is optional, user space has
to request it explicitly. Moreover, user space can inform us about its
view of PCI_COMMAND_INTX_DISABLE so that we can avoid unmasking the
interrupt and signaling it if the guest masked it via the virtualized
PCI config space.

Signed-off-by: Jan Kiszka &lt;jan.kiszka@siemens.com&gt;
Acked-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Acked-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: Avi Kivity &lt;avi@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>KVM: PPC: Add support for explicit HIOR setting</title>
<updated>2012-03-05T12:52:41+00:00</updated>
<author>
<name>Alexander Graf</name>
<email>agraf@suse.de</email>
</author>
<published>2011-09-14T19:45:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1022fc3d3bfaca09d5d6bfcc93a168de16840814'/>
<id>1022fc3d3bfaca09d5d6bfcc93a168de16840814</id>
<content type='text'>
Until now, we always set HIOR based on the PVR, but this is just wrong.
Instead, we should be setting HIOR explicitly, so user space can decide
what the initial HIOR value is - just like on real hardware.

We keep the old PVR based way around for backwards compatibility, but
once user space uses the SET_ONE_REG based method, we drop the PVR logic.

Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
Signed-off-by: Avi Kivity &lt;avi@redhat.com&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Until now, we always set HIOR based on the PVR, but this is just wrong.
Instead, we should be setting HIOR explicitly, so user space can decide
what the initial HIOR value is - just like on real hardware.

We keep the old PVR based way around for backwards compatibility, but
once user space uses the SET_ONE_REG based method, we drop the PVR logic.

Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
Signed-off-by: Avi Kivity &lt;avi@redhat.com&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>KVM: PPC: Add generic single register ioctls</title>
<updated>2012-03-05T12:52:40+00:00</updated>
<author>
<name>Alexander Graf</name>
<email>agraf@suse.de</email>
</author>
<published>2011-09-14T08:02:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e24ed81fedd551e80378be62fa0b0532480ea7d4'/>
<id>e24ed81fedd551e80378be62fa0b0532480ea7d4</id>
<content type='text'>
Right now we transfer a static struct every time we want to get or set
registers. Unfortunately, over time we realize that there are more of
these than we thought of before and the extensibility and flexibility of
transferring a full struct every time is limited.

So this is a new approach to the problem. With these new ioctls, we can
get and set a single register that is identified by an ID. This allows for
very precise and limited transmittal of data. When we later realize that
it's a better idea to shove over multiple registers at once, we can reuse
most of the infrastructure and simply implement a GET_MANY_REGS / SET_MANY_REGS
interface.

Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
Signed-off-by: Avi Kivity &lt;avi@redhat.com&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Right now we transfer a static struct every time we want to get or set
registers. Unfortunately, over time we realize that there are more of
these than we thought of before and the extensibility and flexibility of
transferring a full struct every time is limited.

So this is a new approach to the problem. With these new ioctls, we can
get and set a single register that is identified by an ID. This allows for
very precise and limited transmittal of data. When we later realize that
it's a better idea to shove over multiple registers at once, we can reuse
most of the infrastructure and simply implement a GET_MANY_REGS / SET_MANY_REGS
interface.

Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
Signed-off-by: Avi Kivity &lt;avi@redhat.com&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>KVM: PPC: e500: MMU API</title>
<updated>2012-03-05T12:52:24+00:00</updated>
<author>
<name>Scott Wood</name>
<email>scottwood@freescale.com</email>
</author>
<published>2011-08-18T20:25:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dc83b8bc0256ee682506ed83853a98eaba529c6f'/>
<id>dc83b8bc0256ee682506ed83853a98eaba529c6f</id>
<content type='text'>
This implements a shared-memory API for giving host userspace access to
the guest's TLB.

Signed-off-by: Scott Wood &lt;scottwood@freescale.com&gt;
Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
Signed-off-by: Avi Kivity &lt;avi@redhat.com&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This implements a shared-memory API for giving host userspace access to
the guest's TLB.

Signed-off-by: Scott Wood &lt;scottwood@freescale.com&gt;
Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
Signed-off-by: Avi Kivity &lt;avi@redhat.com&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>KVM: provide synchronous registers in kvm_run</title>
<updated>2012-03-05T12:52:22+00:00</updated>
<author>
<name>Christian Borntraeger</name>
<email>borntraeger@de.ibm.com</email>
</author>
<published>2012-01-11T10:20:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b9e5dc8d4511e6a00862a795319569e7fe7f60f4'/>
<id>b9e5dc8d4511e6a00862a795319569e7fe7f60f4</id>
<content type='text'>
On some cpus the overhead for virtualization instructions is in the same
range as a system call. Having to call multiple ioctls to get set registers
will make certain userspace handled exits more expensive than necessary.
Lets provide a section in kvm_run that works as a shared save area
for guest registers.
We also provide two 64bit flags fields (architecture specific), that will
specify
1. which parts of these fields are valid.
2. which registers were modified by userspace

Each bit for these flag fields will define a group of registers (like
general purpose) or a single register.

Signed-off-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Signed-off-by: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
Signed-off-by: Avi Kivity &lt;avi@redhat.com&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On some cpus the overhead for virtualization instructions is in the same
range as a system call. Having to call multiple ioctls to get set registers
will make certain userspace handled exits more expensive than necessary.
Lets provide a section in kvm_run that works as a shared save area
for guest registers.
We also provide two 64bit flags fields (architecture specific), that will
specify
1. which parts of these fields are valid.
2. which registers were modified by userspace

Each bit for these flag fields will define a group of registers (like
general purpose) or a single register.

Signed-off-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Signed-off-by: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
Signed-off-by: Avi Kivity &lt;avi@redhat.com&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>KVM: s390: ucontrol: announce capability for user controlled vms</title>
<updated>2012-03-05T12:52:20+00:00</updated>
<author>
<name>Carsten Otte</name>
<email>cotte@de.ibm.com</email>
</author>
<published>2012-01-04T09:25:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1efd0f595ab9d10fef1486dfdef952107c91f3db'/>
<id>1efd0f595ab9d10fef1486dfdef952107c91f3db</id>
<content type='text'>
This patch announces a new capability KVM_CAP_S390_UCONTROL that
indicates that kvm can now support virtual machines that are
controlled by userspace.

Signed-off-by: Carsten Otte &lt;cotte@de.ibm.com&gt;
Signed-off-by: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
Signed-off-by: Avi Kivity &lt;avi@redhat.com&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch announces a new capability KVM_CAP_S390_UCONTROL that
indicates that kvm can now support virtual machines that are
controlled by userspace.

Signed-off-by: Carsten Otte &lt;cotte@de.ibm.com&gt;
Signed-off-by: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
Signed-off-by: Avi Kivity &lt;avi@redhat.com&gt;

</pre>
</div>
</content>
</entry>
</feed>
