This code in vhost_scsi_make_tpg() is confusing because we limit "tpgt"
to UINT_MAX but the data type of "tpg->tport_tpgt" and that is a u16.
I looked at the context and it turns out that in
vhost_scsi_set_endpoint(), "tpg->tport_tpgt" is used as an offset into
the vs_tpg[] array which has VHOST_S
On 02/03/2015 11:53 PM, Radim Krčmář wrote:
2015-01-28 10:54+0800, Kai Huang:
This patch adds new kvm_x86_ops dirty logging hooks to enable/disable dirty
logging for particular memory slot, and to flush potentially logged dirty GPAs
before reporting slot->dirty_bitmap to userspace.
kvm x86 com
On 02/03/2015 11:18 PM, Radim Krčmář wrote:
2015-01-28 10:54+0800, Kai Huang:
This patch adds PML support in VMX. A new module parameter 'enable_pml' is added
(+module_param_named(pml, enable_pml, bool, S_IRUGO);)
to allow user to enable/disable it manually.
Signed-off-by: Kai Huang
---
di
On 02/04/2015 01:34 AM, Radim Krčmář wrote:
2015-01-28 10:54+0800, Kai Huang:
This patch adds new mmu layer functions to clear/set D-bit for memory slot, and
to write protect superpages for memory slot.
In case of PML, CPU logs the dirty GPA automatically to PML buffer when CPU
updates D-bit f
On 05.02.15 01:53, David Gibson wrote:
> On POWER, storage caching is usually configured via the MMU - attributes
> such as cache-inhibited are stored in the TLB and the hashed page table.
>
> This makes correctly performing cache inhibited IO accesses awkward when
> the MMU is turned off (real
On Wed, Feb 04, 2015 at 04:24:46PM +0100, Alexander Graf wrote:
>
>
> On 03.02.15 06:44, David Gibson wrote:
> > On POWER, storage caching is usually configured via the MMU - attributes
> > such as cache-inhibited are stored in the TLB and the hashed page table.
> >
> > This makes correctly perf
On POWER, storage caching is usually configured via the MMU - attributes
such as cache-inhibited are stored in the TLB and the hashed page table.
This makes correctly performing cache inhibited IO accesses awkward when
the MMU is turned off (real mode). Some CPU models provide special
registers t
On Wed, Feb 04, 2015 at 01:59:42PM -0800, David Miller wrote:
> From: "Michael S. Tsirkin"
> Date: Tue, 3 Feb 2015 11:07:06 +0200
>
> > In virtio 1.0 mode, when mergeable buffers are enabled on a big-endian
> > host, num_buffers wasn't byte-swapped correctly, so large incoming
> > packets got cor
From: "Michael S. Tsirkin"
Date: Tue, 3 Feb 2015 11:07:06 +0200
> In virtio 1.0 mode, when mergeable buffers are enabled on a big-endian
> host, num_buffers wasn't byte-swapped correctly, so large incoming
> packets got corrupted.
>
> To fix, fill it in within hdr - this also makes sure it gets
Am 04.02.2015 um 14:03 schrieb Paolo Bonzini:
>
>
> On 04/02/2015 14:01, Christian Borntraeger wrote:
>> Am 04.02.2015 um 13:57 schrieb Paolo Bonzini:
>>>
>>>
>>> On 04/02/2015 10:44, Christian Borntraeger wrote:
From: Ekaterina Tumanova
Read the additional data fields (Extended N
The FPU and DSP are enabled via the CP0 Status CU1 and MX bits by
kvm_mips_set_c0_status() on a guest exit, presumably in case there is
active state that needs saving if pre-emption occurs. However neither of
these bits are cleared again when returning to the guest.
This effectively gives the gues
Sorry for all the previous mess, my Claws-mailer went nuts for no reason.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
>Hi,
>
>I've seen the problem quite a few times. Before spending more time on
>it, I'd like to have a quick check here to see if anyone ever saw the
>same problem? Hope it is a relevant question with this mail list.
>
>
>Jul 2 11:08:21 arno-3 kernel: [ 2165.078623] BUG: unable to handle
>kernel
Register a notifier and attempt to unplug when a request for the
device is received.
Signed-off-by: Alex Williamson
---
This is the matching QEMU support for the proposed vfio device request
interface (https://lkml.org/lkml/2015/2/4/425). By default QEMU would
be cooperative, registering for an
When a request is made to unbind a device from a vfio bus driver,
we need to wait for the device to become unused, ie. for userspace
to release the device. However, we have a long standing TODO in
the code to do something proactive to make that happen. To enable
this, we add a request callback on
Currently when the host kernel attempts to unbind an in-use device
from a vfio driver, we simply block until userspace releases the
device. With a cooperative userspace client, we can do better (we can
potentially do better with a non-cooperative client too, but this
series does not attempt to add
Userspace can opt to receive a device request notification,
indicating that the device should be released. This is setup
the same way as the error IRQ and also supports eventfd signaling.
Future support may forcefully remove the device from the user if
the request is ignored.
Signed-off-by: Alex
We want another single vector IRQ index to support signaling of
the device request to userspace. Generalize the error reporting
IRQ index to avoid code duplication.
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci_intrs.c | 44 -
1 file changed
Move the iommu_group reference from the device to the vfio_group.
This ensures that the iommu_group persists as long as the vfio_group
remains. This can be important if all of the device from an
iommu_group are removed, but we still have an outstanding vfio_group
reference; we can still walk the e
There's a small window between the vfio bus driver calling
vfio_del_group_dev() and the device being completely unbound where
the vfio group appears to be non-viable. This creates a race for
users like QEMU/KVM where the kvm-vfio module tries to get an
external reference to the group in order to m
In PCI config space there is an interrupt line field (offset 0x3f),
which is used to initially communicate the IRQ line number from
firmware to the OS. _Hardware_ should never use this information,
as the OS is free to write any information in there.
But kvmtool uses this number when it triggers IR
On 03.02.15 06:44, David Gibson wrote:
> On POWER, storage caching is usually configured via the MMU - attributes
> such as cache-inhibited are stored in the TLB and the hashed page table.
>
> This makes correctly performing cache inhibited IO accesses awkward when
> the MMU is turned off (real
Am 04.02.2015 um 13:57 schrieb Paolo Bonzini:
>
>
> On 04/02/2015 10:44, Christian Borntraeger wrote:
>> commit 7be81a46695d ("KVM: s390/facilities: allow TOD-CLOCK steering
>> facility bit") accidentially disabled the "load program parameter"
>> facility bit during rebase for upstream submission
Am 04.02.2015 um 14:48 schrieb Paolo Bonzini:
>
>
> On 04/02/2015 14:05, Christian Borntraeger wrote:
Could this also be part of the "things" that KVM can choose to enable,
even though it's not a facility?
>> Can you re-ask that question? Not sure what you want to know.
>>
>> This
On 04/02/2015 14:05, Christian Borntraeger wrote:
>> >
>> > Could this also be part of the "things" that KVM can choose to enable,
>> > even though it's not a facility?
> Can you re-ask that question? Not sure what you want to know.
>
> This is mostly a fixup for z13, which wants to have a big
On Wed, Feb 04, 2015 at 02:55:12AM -0800, Nicholas A. Bellinger wrote:
> On Wed, 2015-02-04 at 02:41 -0800, Nicholas A. Bellinger wrote:
> > On Wed, 2015-02-04 at 10:42 +0100, Michael S. Tsirkin wrote:
> > > On Wed, Feb 04, 2015 at 01:40:25AM -0800, Nicholas A. Bellinger wrote:
> > > > > > +
On Wed, Feb 04, 2015 at 02:41:07AM -0800, Nicholas A. Bellinger wrote:
> On Wed, 2015-02-04 at 10:42 +0100, Michael S. Tsirkin wrote:
> > On Wed, Feb 04, 2015 at 01:40:25AM -0800, Nicholas A. Bellinger wrote:
> > > > > + /*
> > > > > + * Any associated T10_PI bytes for the
On Wed, Feb 04, 2015 at 02:41:07AM -0800, Nicholas A. Bellinger wrote:
> On Wed, 2015-02-04 at 10:42 +0100, Michael S. Tsirkin wrote:
> > On Wed, Feb 04, 2015 at 01:40:25AM -0800, Nicholas A. Bellinger wrote:
> > > > > + /*
> > > > > + * Any associated T10_PI bytes for the
Am 04.02.2015 um 14:00 schrieb Paolo Bonzini:
>
>
> On 04/02/2015 10:44, Christian Borntraeger wrote:
>> +static void kvm_s390_set_crycb_format(struct kvm *kvm)
>> +{
>> +kvm->arch.crypto.crycbd = (__u32)(unsigned long) kvm->arch.crypto.crycb;
>> +
>> +if (kvm_s390_apxa_installed())
>> +
On 04/02/2015 14:01, Christian Borntraeger wrote:
> Am 04.02.2015 um 13:57 schrieb Paolo Bonzini:
>>
>>
>> On 04/02/2015 10:44, Christian Borntraeger wrote:
>>> From: Ekaterina Tumanova
>>>
>>> Read the additional data fields (Extended Name and UUID) from the
>>> 1KB block returned by the STSI c
On 04/02/2015 10:44, Christian Borntraeger wrote:
> here is my remaining bunch of patches for 3.20 for review. All patches
> have been in linux-next via
> git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git next
> (well a tiny fix went in today, so the commit id for the last 3 patches
Am 04.02.2015 um 13:57 schrieb Paolo Bonzini:
>
>
> On 04/02/2015 10:44, Christian Borntraeger wrote:
>> From: Ekaterina Tumanova
>>
>> Read the additional data fields (Extended Name and UUID) from the
>> 1KB block returned by the STSI command and reflect this information in
>> the /proc/sysinfo
On 04/02/2015 10:44, Christian Borntraeger wrote:
> +static void kvm_s390_set_crycb_format(struct kvm *kvm)
> +{
> + kvm->arch.crypto.crycbd = (__u32)(unsigned long) kvm->arch.crypto.crycb;
> +
> + if (kvm_s390_apxa_installed())
> + kvm->arch.crypto.crycbd |= CRYCB_FORMAT2;
>
On 04/02/2015 10:44, Christian Borntraeger wrote:
> From: Ekaterina Tumanova
>
> Read the additional data fields (Extended Name and UUID) from the
> 1KB block returned by the STSI command and reflect this information in
> the /proc/sysinfo file accordingly
>
> Signed-off-by: Ekaterina Tumanova
On 04/02/2015 10:44, Christian Borntraeger wrote:
> commit 7be81a46695d ("KVM: s390/facilities: allow TOD-CLOCK steering
> facility bit") accidentially disabled the "load program parameter"
> facility bit during rebase for upstream submission (my fault).
>
> Re-add that bit.
>
> Signed-off-by:
On 04/02/2015 12:27, Christian Borntraeger wrote:
> We never had a 31bit QEMU/kuli running. We would need to review several
> ioctls to check if this creates holes, bugs or whatever to make it work.
> Lets just disable compat support for KVM on s390.
>
> Signed-off-by: Christian Borntraeger
> -
Am 04.02.2015 um 12:42 schrieb Paolo Bonzini:
>
>
> On 04/02/2015 12:25, Christian Borntraeger wrote:
>> Whenever vhost or qemu or a finished aio request wrote content into a
>> virtio buffer, the HW has set the storage key for that physical page,
>> which makes it automatically dirty/referenced
On 04/02/2015 12:25, Christian Borntraeger wrote:
> Whenever vhost or qemu or a finished aio request wrote content into a
> virtio buffer, the HW has set the storage key for that physical page,
> which makes it automatically dirty/referenced in the guest visible
> storage key.
Ah, I knew the s
We never had a 31bit QEMU/kuli running. We would need to review several
ioctls to check if this creates holes, bugs or whatever to make it work.
Lets just disable compat support for KVM on s390.
Signed-off-by: Christian Borntraeger
---
virt/kvm/Kconfig| 4
virt/kvm/kvm_main.c | 12
Am 04.02.2015 um 11:39 schrieb Paolo Bonzini:
>> Conny:
>> I am asking myself, if we should explicitly add a comment in the
>> virtio-ccw spec, that all accesses are assumed to be with key 0 and
>> thus never cause key protection. The change/reference bit is set
>> by the underlying I/O or memory
On Wed, 04 Feb 2015 09:26:11 +0100
Christian Borntraeger wrote:
> Am 03.02.2015 um 16:22 schrieb Paolo Bonzini:
> >
> >
> > On 03/02/2015 16:16, Thomas Huth wrote:
> >> Actually, I'd prefer to keep the "virtual" in the defines for the type
> >> of operation below: When it comes to s390 storage
On Wed, 2015-02-04 at 02:41 -0800, Nicholas A. Bellinger wrote:
> On Wed, 2015-02-04 at 10:42 +0100, Michael S. Tsirkin wrote:
> > On Wed, Feb 04, 2015 at 01:40:25AM -0800, Nicholas A. Bellinger wrote:
> > > > > + /*
> > > > > + * Any associated T10_PI bytes for the outgoin
Ensure any hardware page table walker (HTW) is disabled while in KVM
guest mode, as KVM doesn't yet set up hardware page table walking for
guest mappings so the wrong mappings would get loaded, resulting in the
guest hanging or crashing once it reaches userland.
The HTW is disabled and re-enabled
On Wed, 2015-02-04 at 10:42 +0100, Michael S. Tsirkin wrote:
> On Wed, Feb 04, 2015 at 01:40:25AM -0800, Nicholas A. Bellinger wrote:
> > > > + /*
> > > > +* Any associated T10_PI bytes for the outgoing /
> > > > incoming
> > > > +* payloads are includ
On Wed, 2015-02-04 at 11:20 +0100, Michael S. Tsirkin wrote:
> On Wed, Feb 04, 2015 at 02:11:20AM -0800, Nicholas A. Bellinger wrote:
> > On Tue, 2015-02-03 at 23:56 +, Al Viro wrote:
> > > On Tue, Feb 03, 2015 at 06:29:59AM +, Nicholas A. Bellinger wrote:
> > > > +* Copy ov
On 04/02/2015 09:26, Christian Borntraeger wrote:
> Am 03.02.2015 um 16:22 schrieb Paolo Bonzini:
>> On 03/02/2015 16:16, Thomas Huth wrote:
>>> Actually, I'd prefer to keep the "virtual" in the defines for the type
>>> of operation below: When it comes to s390 storage keys, we likely might
>>> n
On Wed, Feb 04, 2015 at 02:11:20AM -0800, Nicholas A. Bellinger wrote:
> On Tue, 2015-02-03 at 23:56 +, Al Viro wrote:
> > On Tue, Feb 03, 2015 at 06:29:59AM +, Nicholas A. Bellinger wrote:
> > > + * Copy over the virtio-scsi request header, which when
> > > + * ANY_LAYOUT
On Tue, 2015-02-03 at 23:56 +, Al Viro wrote:
> On Tue, Feb 03, 2015 at 06:29:59AM +, Nicholas A. Bellinger wrote:
> > +* Copy over the virtio-scsi request header, which when
> > +* ANY_LAYOUT is enabled may span multiple iovecs, or a
> > +* single iovec
From: Ekaterina Tumanova
Read the additional data fields (Extended Name and UUID) from the
1KB block returned by the STSI command and reflect this information in
the /proc/sysinfo file accordingly
Signed-off-by: Ekaterina Tumanova
Reviewed-by: David Hildenbrand
Reviewed-by: Cornelia Huck
Acke
From: Michael Mueller
The patch introduces facilities and cpu_ids per virtual machine.
Different virtual machines may want to expose different facilities and
cpu ids to the guest, so let's make them per-vm instead of global.
Signed-off-by: Michael Mueller
Reviewed-by: Cornelia Huck
Reviewed-by
From: Tony Krowiak
We need to specify a different format for the crypto control block
depending on whether the APXA facility is installed or not. Let's test
for it by executing the PQAP(QCI) function and use either a format-1 or
a format-2 crypto control block accordingly.
Signed-off-by: Tony Kr
From: "Jason J. Herne"
Provide the KVM_S390_GET_SKEYS and KVM_S390_SET_SKEYS ioctl which can be used
to get/set guest storage keys. This functionality is needed for live migration
of s390 guests that use storage keys.
Signed-off-by: Jason J. Herne
Reviewed-by: David Hildenbrand
Signed-off-by:
commit 7be81a46695d ("KVM: s390/facilities: allow TOD-CLOCK steering
facility bit") accidentially disabled the "load program parameter"
facility bit during rebase for upstream submission (my fault).
Re-add that bit.
Signed-off-by: Christian Borntraeger
Reviewed-by: David Hildenbrand
Acked-by: C
From: Michael Mueller
This patch enables cpu model support in kvm/s390 via the vm attribute
interface.
During KVM initialization, the host properties cpuid, IBC value and the
facility list are stored in the architecture specific cpu model structure.
During vcpu setup, these properties are taken
From: David Hildenbrand
If a vm with no VCPUs is created, the injection of a floating irq
leads to an endless loop in the kernel.
Let's skip the search for a destination VCPU for a floating irq if no
VCPUs were created.
Reviewed-by: Dominik Dingel
Reviewed-by: Cornelia Huck
Signed-off-by: Dav
Paolo,
here is my remaining bunch of patches for 3.20 for review. All patches
have been in linux-next via
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git next
(well a tiny fix went in today, so the commit id for the last 3 patches
has changed)
I think it makes sense to give some o
On Wed, Feb 04, 2015 at 01:40:25AM -0800, Nicholas A. Bellinger wrote:
> > > + /*
> > > + * Any associated T10_PI bytes for the outgoing / incoming
> > > + * payloads are included in calculation of exp_data_len here.
> > > + */
> > > + if (out_size > req_s
On Tue, 2015-02-03 at 12:14 +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 03, 2015 at 06:29:59AM +, Nicholas A. Bellinger wrote:
> > From: Nicholas Bellinger
> >
> > This patch adds ANY_LAYOUT support with a new vqs[].vq.handle_kick()
> > callback in vhost_scsi_handle_vqal().
> >
> > It cal
On Wed, Feb 04, 2015 at 01:13:58AM -0800, Nicholas A. Bellinger wrote:
> On Tue, 2015-02-03 at 11:40 +0200, Michael S. Tsirkin wrote:
> > On Tue, Feb 03, 2015 at 06:30:00AM +, Nicholas A. Bellinger wrote:
> > > From: Nicholas Bellinger
> > >
> > > Signal support of VIRTIO_F_ANY_LAYOUT + VIRTI
On Tue, 2015-02-03 at 11:40 +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 03, 2015 at 06:30:00AM +, Nicholas A. Bellinger wrote:
> > From: Nicholas Bellinger
> >
> > Signal support of VIRTIO_F_ANY_LAYOUT + VIRTIO_F_VERSION_1 feature bits
> > required for virtio-scsi 1.0 spec layout requireme
On Wed, Feb 04, 2015 at 06:40:07AM +, Al Viro wrote:
> From: Al Viro
>
> just advance the msg.msg_iter and be done with that.
>
> Cc: Michael S. Tsirkin
> Cc: kvm@vger.kernel.org
> Cc: virtualizat...@lists.linux-foundation.org
> Signed-off-by: Al Viro
Acked-by: Michael S. Tsirkin
> ---
On Wed, Feb 04, 2015 at 06:40:09AM +, Al Viro wrote:
> From: Al Viro
>
> it has just verified that it asks no more than the length of the
> first segment of iovec.
>
> And with that the last user of stuff in lib/iovec.c is gone.
> RIP.
>
> Cc: Michael S. Tsirkin
> Cc: Nicholas A. Bellinger
On Tue, 2015-02-03 at 11:37 +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 03, 2015 at 06:30:01AM +, Nicholas A. Bellinger wrote:
> > From: Nicholas Bellinger
> >
> > With the new ANY_LAYOUT logic in place for vhost_scsi_handle_vqal(),
> > there is no longer a reason to keep around the legacy
> if (likely(mergeable) &&
> - memcpy_toiovecend(nvq->hdr, (unsigned char *)&headcount,
> - offsetof(typeof(hdr), num_buffers),
> - sizeof hdr.num_buffers)) {
> + copy_to_iter(&headcoun
On Wed, Feb 04, 2015 at 06:40:08AM +, Al Viro wrote:
> From: Al Viro
>
> Cc: Michael S. Tsirkin
> Cc: kvm@vger.kernel.org
> Cc: virtualizat...@lists.linux-foundation.org
> Signed-off-by: Al Viro
Acked-by: Michael S. Tsirkin
> ---
> drivers/vhost/net.c | 82
> +++
On Wed, Feb 04, 2015 at 06:40:06AM +, Al Viro wrote:
> From: Al Viro
>
> Cc: Michael S. Tsirkin
> Cc: kvm@vger.kernel.org
> Cc: virtualizat...@lists.linux-foundation.org
> Signed-off-by: Al Viro
Acked-by: Michael S. Tsirkin
> ---
> drivers/vhost/vhost.c | 6 --
> include/linux/uio.
On Tue, 2015-02-03 at 11:35 +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 03, 2015 at 06:29:54AM +, Nicholas A. Bellinger wrote:
> > From: Nicholas Bellinger
> >
> > Hi MST, Paolo, Al & Co,
> >
> > Here is -v3 for adding vhost/scsi ANY_LAYOUT + VERSION_1 host feature
> > bit support.
> >
>
On Tue, 2015-02-03 at 11:32 +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 03, 2015 at 06:29:58AM +, Nicholas A. Bellinger wrote:
> > From: Nicholas Bellinger
> >
> > This patch adds ANY_LAYOUT prerequisites logic for accepting a set of
> > protection + data payloads via iov_iter. Also inclu
On Tue, 2015-02-03 at 11:24 +0200, Michael S. Tsirkin wrote:
>
> On Tue, Feb 03, 2015 at 06:29:55AM +, Nicholas A. Bellinger wrote:
> > From: Nicholas Bellinger
> >
> > Required for ANY_LAYOUT support when the incoming virtio-scsi response
> > header + fixed size sense buffer payload may spa
Am 03.02.2015 um 16:22 schrieb Paolo Bonzini:
>
>
> On 03/02/2015 16:16, Thomas Huth wrote:
>> Actually, I'd prefer to keep the "virtual" in the defines for the type
>> of operation below: When it comes to s390 storage keys, we likely might
>> need some calls for reading and writing to physical m
70 matches
Mail list logo
