"Michael S. Tsirkin" writes:
> Defer config changed notifications that arrive during
> probe/scan/freeze/restore.
>
> This will allow drivers to set DRIVER_OK earlier, without worrying about
> racing with config change interrupts.
>
> This change will also benefit old hypervisors (before 2009)
> t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 13/10/2014 09:48, Nadav Amit ha scritto:
> Can it be related to the MTRR issue I caused? Did you push commit
> 0d234daf7e0a3290a3a20c8087eefbd6335a5bd4 ("Revert "KVM: x86:
> Increase the number of fixed MTRR regs to 10??) to stable?
Hmm, I typo-ed
--
Dear user,
We are undergoing maintenance therefore all accounts must be updated,
this is to reduce the number of dormant accounts.
Accounts not updated in 48 hours will be suspended.
Please follow the hyper link below to update your account
Click Here To Update Account.
http://zimbra1.my3gb.c
I don't know what's going on here, but a nested VMX boot using -cpu
host on SNB on L0 and L1 fails with the OOPS below. I kind of suspect
that there's both a KVM bug and an APIC driver bug here.
-cpu host,-tsc-deadline on L1 works around the OOPS.
[0.184000] Freeing SMP alternatives memory:
On 10/13/2014 02:41 PM, Alex Williamson wrote:
On Mon, 2014-10-13 at 13:50 -0700, Jan Sacha wrote:
We have tried two different Linux distributions (CentOS and Fedora)...
This doesn't really help narrow your kernel version.
Fedora kernel was 3.11.10-100.fc18 and CentOS kernel was an older
2.6.
On Mon, 2014-10-13 at 13:50 -0700, Jan Sacha wrote:
> Hi,
>
> I have a question about IOTLB. We are running KVM/Qemu VMs with huge
> page memory backing on Intel Xeon Ivy Bridge machines. Our VMs use 10G
> Ether NICs in Intel VT-d mode. We actually see that IOTLB becomes a
> performance bottlen
Hi,
I have a question about IOTLB. We are running KVM/Qemu VMs with huge
page memory backing on Intel Xeon Ivy Bridge machines. Our VMs use 10G
Ether NICs in Intel VT-d mode. We actually see that IOTLB becomes a
performance bottleneck when IOMMU uses 4k pages. We get much better
packet throug
I hope I don’t waste your time, but I think I encountered a similar scenario in
a different environment.
If you want, you can try this patch: https://lkml.org/lkml/2014/6/30/195
Nadav
On Oct 13, 2014, at 6:58 PM, bugzilla-dae...@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug
https://bugzilla.kernel.org/show_bug.cgi?id=86161
--- Comment #2 from GC Ngu ---
There is a simple to recreate the error:
* Send an nmi command to the guest through monitor. The guest will be halted.
* Then send 'system_reset' command. The guest will be reset. Let the system
start normally, then
https://bugzilla.kernel.org/show_bug.cgi?id=86161
--- Comment #1 from GC Ngu ---
After long time bisection, I narrowed down the problem to the commit
"5a71785dde307f6ac80e83c0ad3fd694912010a1".
But I have no idea why it happens sometimes instead of every time.
Could anyone make a fix for this?
On 10/13/14 22:47, Alexander Graf wrote:
>
> Could you please instead rewrite it to use g_strdup_printf() rather than
> strncat()s? That way we resolve all string pitfalls automatically - and
> this code is not the fast path, so doing an extra memory allocation is ok.
>
I guess, it is a personal
On 13.10.14 16:36, Chen Gang wrote:
> strncat() will append additional '\0' to destination buffer, so need
> additional 1 byte for it, or may cause memory overflow, just like other
> area within QEMU have done.
>
> Signed-off-by: Chen Gang
I agree with this patch. However, the code is pretty u
strncat() will append additional '\0' to destination buffer, so need
additional 1 byte for it, or may cause memory overflow, just like other
area within QEMU have done.
Signed-off-by: Chen Gang
---
target-ppc/kvm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target-pp
This allows to make use of the VFIO_IOMMU_TYPE1 driver with platform
devices on ARM. The driver can then be used with an Exynos SMMU, or
ARM SMMU driver.
Signed-off-by: Antonios Motakis
---
drivers/vfio/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vfio/Kcon
We introduce the VFIO_DMA_MAP_FLAG_NOEXEC flag to the VFIO dma map call,
and expose its availability via the capability VFIO_DMA_NOEXEC_IOMMU.
This way the user can control whether the XN flag will be set on the
requested mappings. The IOMMU_NOEXEC flag needs to be available for all
the IOMMUs of t
This patch forms the common skeleton code for platform devices support
with VFIO. This will include the core functionality of VFIO_PLATFORM,
however binding to the device and discovering the device resources will
be done with the help of a separate file where any Linux platform bus
specific code wi
Driver to bind to Linux platform devices, and callbacks to discover their
resources to be used by the main VFIO PLATFORM code.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_platform.c | 107 ++
include/uapi/linux/vfio.h | 1 +
2 file
Enable building the VFIO PLATFORM driver that allows to use Linux platform
devices with VFIO.
Signed-off-by: Antonios Motakis
---
drivers/vfio/Kconfig | 1 +
drivers/vfio/Makefile | 1 +
drivers/vfio/platform/Kconfig | 9 +
drivers/vfio/platform/Makefile | 4
4 f
Enable building the VFIO AMBA driver. VFIO_AMBA depends on VFIO_PLATFORM,
since it is sharing a portion of the code, and it is essentially implemented
as a platform device whose resources are discovered via AMBA specific APIs
in the kernel.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platfo
Add support for discovering AMBA devices with VFIO and handle them
similarly to Linux platform devices.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_amba.c | 108 ++
include/uapi/linux/vfio.h | 1 +
2 files changed, 109 insertions(+
A VFIO userspace driver will start by opening the VFIO device
that corresponds to an IOMMU group, and will use the ioctl interface
to get the basic device info, such as number of memory regions and
interrupts, and their properties. This patch enables the
VFIO_DEVICE_GET_INFO ioctl call.
Signed-off
Allow to memory map the MMIO regions of the device so userspace can
directly access them. PIO regions are not being handled at this point.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_platform_common.c | 57
1 file changed, 57 insertions(+)
diff --
VFIO returns a file descriptor which we can use to manipulate the memory
regions of the device. Usually, the user will mmap memory regions that are
addressable on page boundaries, however for memory regions where this is
not the case we cannot provide mmap functionality due to security concerns.
Fo
This patch enables the IOCTLs VFIO_DEVICE_GET_REGION_INFO ioctl call,
which allows the user to learn about the available MMIO resources of
a device.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_platform_common.c | 93 +--
drivers/vfio/platform/vfio_plat
Adds support to mask interrupts, and also for automasked interrupts.
Level sensitive interrupts are exposed as automasked interrupts and
are masked and disabled automatically when they fire.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_platform_irq.c | 94 ++
VFIO_PCI passes the VFIO device structure *vdev via eventfd to the handler
that implements masking/unmasking of IRQs via an eventfd. We can replace
it in the virqfd infrastructure with an opaque type so we can make use
of the mechanism from other VFIO bus drivers.
Signed-off-by: Antonios Motakis
Virqfd just needs to keep accesses to any struct *virqfd safe, but this
comes into play only when creating or destroying eventfds, so sharing
the same spinlock with the VFIO bus driver is not necessary.
Signed-off-by: Antonios Motakis
---
drivers/vfio/pci/vfio_pci_intrs.c | 10 +-
driver
The virqfd functionality that is used by VFIO_PCI to implement interrupt
masking and unmasking via an eventfd, is generic enough and can be reused
by another driver. Move it to a separate file in order to allow the code
to be shared.
Also properly export virqfd_enable and virqfd_disable in the pro
This patch is a skeleton for the VFIO_DEVICE_SET_IRQS IOCTL, around which
most IRQ functionality is implemented in VFIO.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_platform_common.c | 52 +++--
drivers/vfio/platform/vfio_platform_irq.c | 56 ++
This patch allows to set an eventfd for a patform device's interrupt,
and also to trigger the interrupt eventfd from userspace for testing.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_platform_irq.c | 83 ++-
drivers/vfio/platform/vfio_platform_priv
Return information for the interrupts exposed by the device.
This patch extends VFIO_DEVICE_GET_INFO with the number of IRQs
and enables VFIO_DEVICE_GET_IRQ_INFO.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/Makefile| 2 +-
drivers/vfio/platform/vfio_platform_common
Now we have finally completely decoupled virqfd from VFIO_PCI. We can
initialize it from the VFIO generic code, in order to safely use it from
multiple independent VFIO bus drivers.
Signed-off-by: Antonios Motakis
---
drivers/vfio/pci/vfio_pci.c | 8
drivers/vfio/vfio.c | 8
With this patch the VFIO user will be able to set an eventfd that can be
used in order to mask and unmask IRQs of platform devices.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/vfio_platform_irq.c | 46 ---
drivers/vfio/platform/vfio_platform_private.h |
Replace the function vfio_domains_have_iommu_cache() with a more generic
function vfio_domains_have_iommu_cap() which allows to check all domains
of an vfio_iommu structure for a given cached capability.
Signed-off-by: Antonios Motakis
---
drivers/vfio/vfio_iommu_type1.c | 37 +++
VFIO_IOMMU_TYPE1 keeps track for each domain it knows a list of protection
flags it always applies to all mappings in the domain. This is used for
domains that support IOMMU_CAP_CACHE_COHERENCY.
Refactor this slightly, by keeping track instead that a given domain
supports the capability, and apply
Some IOMMU drivers, such as the ARM SMMU driver, make available the
IOMMU_NOEXEC flag, to set the page tables for a device as XN (execute never).
This affects devices such as the ARM PL330 DMA Controller, which respects
this flag and will refuse to fetch DMA instructions from memory where the
XN fl
On Mon, Oct 13, 2014 at 02:15:43AM +0300, Nadav Amit wrote:
>
>
> On 10/12/14 3:12 PM, Paolo Bonzini wrote:
> > Il 12/10/2014 08:57, Nadav Amit ha scritto:
> >> Looks good. I’ll give it a try but it is hard to give a definitive
> >> answer, since the emulator is still bug-ridden.
> >
> > Yes, we
On Monday 13 October 2014 02:50:08 Alex Williamson wrote:
>
> Why wouldn't we handle this with stubs for `get_cached_msi_msg' and
> `write_msi_msg'? We're really not talking about much code that might
> get removed by the compiler with this static branch and and it seems
> like a rather non-stand
On Mon, 13 Oct 2014 16:23:58 +1030
Rusty Russell wrote:
> Cornelia Huck writes:
> > With virtio-1, we support more than 32 feature bits. Let's make
> > vdev->guest_features depend on the number of supported feature bits,
> > allowing us to grow the feature bits automatically.
>
> It's a judgeme
On Mon, 13 Oct 2014 16:28:32 +1030
Rusty Russell wrote:
> Cornelia Huck writes:
> > Note that we care only about the fields still in use for virtio v1.0.
> >
> > Reviewed-by: Thomas Huth
> > Reviewed-by: David Hildenbrand
> > Signed-off-by: Cornelia Huck
>
> Hi Cornelia,
>
> These p
Currently, all group15 instructions are decoded as clflush (e.g., mfence,
xsave). In addition, the clflush instruction requires no prefix (66/f2/f3)
would exist. If prefix exists it may encode a different instruction (e.g.,
clflushopt).
Creating a group for clflush, and different group for each p
The decode phase of the x86 emulator assumes that every instruction with the
ModRM flag, and which can be used with RIP-relative addressing, has either
SrcMem or DstMem. This is not the case for several instructions - prefetch,
hint-nop and clflush.
Adding SrcMem|NoAccess for prefetch and hint-no
This patch-set handles two problems. First, all group15 instructions are
decoded as clflush. Second, prefetch, hint_nop and clflush cause the decoder to
oops if they are executed with rip-relative addressing.
Thanks for reviewing the patches.
Nadav Amit (2):
KVM: x86: Emulator does not decode
https://bugzilla.kernel.org/show_bug.cgi?id=86161
GC Ngu changed:
What|Removed |Added
Summary|PROBLEM: On KVM, Window 7 |PROBLEM: On KVM, Windows 7
|32
On Fri, Oct 10, 2014 at 04:09:29PM +0300, Gleb Natapov wrote:
> On Wed, Oct 08, 2014 at 04:22:31PM -0300, Marcelo Tosatti wrote:
> > > >
> > > > Argh, lets try again:
> > > >
> > > > skip_pinned = true
> > > > --
> > > >
> > > > mark page dirty, keep spte intact
> > > >
> > > >
On Thu, 2014-10-09 at 10:40 +0200, Arnd Bergmann wrote:
> A recent bug fix to the MSIx handling in vfio added references
> to functions that may not be defined if MSI is disabled in the kernel,
> resulting in this link error:
>
> drivers/built-in.o: In function `vfio_msi_set_vector_signal':
> :(.t
config_mutex served two purposes: prevent multiple concurrent config
change handlers, and synchronize access to config_enable flag.
Since commit dbf2576e37da0fcc7aacbfbb9fd5d3de7888a3c1
workqueue: make all workqueues non-reentrant
all workqueues are non-reentrant, and config_enable
is now gone
Now that virtio core ensures config changes don't
arrive during probing, drop config_enable flag
in virtio blk.
On removal, flush is now sufficient to guarantee that
no change work is queued.
This help simplify the driver, and will allow
setting DRIVER_OK earlier without losing config
change notif
This is in preparation to extending config changed event handling
in core.
Wrapping these in an API also seems to make for a cleaner code.
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Cornelia Huck
---
include/linux/virtio.h | 6 +
drivers/virtio/virtio.c | 54 ++
Defer config changed notifications that arrive during
probe/scan/freeze/restore.
This will allow drivers to set DRIVER_OK earlier, without worrying about
racing with config change interrupts.
This change will also benefit old hypervisors (before 2009)
that send interrupts without checking DRIVER_
goto done;
done:
return;
is ugly, it was put there to make diff review easier.
replace by open-coded return.
Signed-off-by: Michael S. Tsirkin
Acked-by: Cornelia Huck
---
drivers/net/virtio_net.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/n
virtio spec requires drivers to set DRIVER_OK before using VQs.
This is set automatically after probe returns, virtio block violated this
rule by calling add_disk, which causes the VQ to be used directly within
probe.
To fix, call virtio_device_ready before using VQs.
Signed-off-by: Michael S. Ts
virtio spec requires drivers to set DRIVER_OK before using VQs.
This is set automatically after probe returns, virtio net violated this
rule by using receive VQs within probe.
To fix, call virtio_device_ready before using VQs.
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Cornelia Huck
---
dr
virtio spec 0.9.X requires DRIVER_OK to be set before
VQs are used, but some drivers use VQs before probe
function returns.
Since DRIVER_OK is set after probe, this violates the spec.
Even though under virtio 1.0 transitional devices support this
behaviour, we want to make it possible for those ea
Now that virtio core ensures config changes don't arrive during probing,
drop config_enable flag in virtio net.
On removal, flush is now sufficient to guarantee that no change work is
queued.
This help simplify the driver, and will allow setting DRIVER_OK earlier
without losing config change notif
config_mutex served two purposes: prevent multiple concurrent config
change handlers, and synchronize access to config_enable flag.
Since commit dbf2576e37da0fcc7aacbfbb9fd5d3de7888a3c1
workqueue: make all workqueues non-reentrant
all workqueues are non-reentrant, and config_enable
is now gone
virtio spec requires drivers to set DRIVER_OK before using VQs.
This is set automatically after probe returns, but virtio 9p device
adds self to channel list within probe, at which point VQ can be
used in violation of the spec.
To fix, call virtio_device_ready before using VQs.
Signed-off-by: Mic
virtio spec requires drivers to set DRIVER_OK before using VQs.
This is set automatically after resume returns, virtio console violated this
rule by adding inbufs, which causes the VQ to be used directly within
restore.
To fix, call virtio_device_ready before using VQs.
Signed-off-by: Michael S.
virtio spec requires drivers to set DRIVER_OK before using VQs.
This is set automatically after restore returns, virtio block violated
this rule on restore by restarting queues, which might in theory
cause the VQ to be used directly within restore.
To fix, call virtio_device_ready before using sta
In the extremely unlikely event that driver initialization fails after
RX buffers are added, virtio net frees RX buffers while VQs are
still active, potentially causing device to use a freed buffer.
To fix, reset device first - same as we do on device removal.
Signed-off-by: Michael S. Tsirkin
R
virtio spec requires drivers to set DRIVER_OK before using VQs.
This is set automatically after restore returns, virtio scsi violated
this rule on restore by kicking event vq within restore.
To fix, call virtio_device_ready before using event queue.
Signed-off-by: Michael S. Tsirkin
---
drivers
virtio spec requires drivers to set DRIVER_OK before using VQs.
This is set automatically after probe returns, virtio console violated this
rule by adding inbufs, which causes the VQ to be used directly within
probe.
To fix, call virtio_device_ready before using VQs.
Signed-off-by: Michael S. Tsi
virtio spec requires drivers to set DRIVER_OK before using VQs.
This is set automatically after restore returns, virtio net violated this
rule by using receive VQs within restore.
To fix, call virtio_device_ready before using VQs.
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Cornelia Huck
---
Paolo,
Can it be related to the MTRR issue I caused?
Did you push commit 0d234daf7e0a3290a3a20c8087eefbd6335a5bd4 ("Revert "KVM:
x86: Increase the number of fixed MTRR regs to 10””) to stable?
Thanks,
Nadav
On Oct 13, 2014, at 5:14 AM, bugzilla-dae...@bugzilla.kernel.org wrote:
> https://bugzi
virtio spec requires drivers to set DRIVER_OK before using VQs.
This is set automatically after resume returns, virtio balloon
violated this rule by adding bufs, which causes the VQ to be used
directly within restore.
To fix, call virtio_device_ready before using VQ.
Signed-off-by: Michael S. Tsi
We cancel event work on device removal, but an interrupt
could trigger immediately after this, and queue it
again.
To fix, set a flag.
Loosely based on patch by Paolo Bonzini
Signed-off-by: Paolo Bonzini
Signed-off-by: Michael S. Tsirkin
---
drivers/scsi/virtio_scsi.c | 11 ++-
1 file
From: Paolo Bonzini
Michael S. Tsirkin noticed a race condition:
we reset device on freeze, but system WQ is still
running so it might try adding bufs to a VQ meanwhile.
To fix, switch to handling events from the freezable WQ.
Reported-by: Michael S. Tsirkin
Signed-off-by: Paolo Bonzini
Signe
Code like
vi->vq = NULL;
kfree(vi)
does not make sense.
Clean it up, use goto error labels for cleanup.
Signed-off-by: Michael S. Tsirkin
---
drivers/char/hw_random/virtio-rng.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/char/hw_r
Enable VQs early like we do for restore.
This makes it possible to drop the scan callback,
moving scanning into the probe function, and making
code simpler.
Signed-off-by: Michael S. Tsirkin
---
drivers/scsi/virtio_scsi.c | 23 +++
1 file changed, 7 insertions(+), 16 deletion
We currently kick event within virtscsi_init,
before host is fully initialized.
This can in theory confuse guest if device
consumes the buffers immediately.
To fix, move virtscsi_kick_event_all out to scan/restore.
Signed-off-by: Michael S. Tsirkin
---
drivers/scsi/virtio_scsi.c | 16
Replace duplicated code in all transports with a single wrapper in
virtio.c.
The only functional change is in virtio_mmio.c: if a buggy device sends
us an interrupt before driver is set, we previously returned IRQ_NONE,
now we return IRQ_HANDLED.
As this must not happen in practice, this does not
On restore, virtio pci does the following:
+ set features
+ init vqs etc - device can be used at this point!
+ set ACKNOWLEDGE,DRIVER and DRIVER_OK status bits
This is in violation of the virtio spec, which
requires the following order:
- ACKNOWLEDGE
- DRIVER
- init vqs
- DRIVER_OK
This behaviour
Changes from v4:
rename virtio_enable_vqs_early() to virtio_device_ready()
Note: Rusty requested we add a BUG_ON in the virtio_ring code.
This can be done by a separate patch on top.
Good for bisectability in case BUG_ON starts triggering :)
Rusty, please review this, and c
On Mon, Oct 13, 2014 at 05:22:39PM +1030, Rusty Russell wrote:
> "Michael S. Tsirkin" writes:
> > virtio spec 0.9.X requires DRIVER_OK to be set before
> > VQs are used, but some drivers use VQs before probe
> > function returns.
> > Since DRIVER_OK is set after probe, this violates the spec.
> >
On Mon, Oct 13, 2014 at 02:22:12PM +0800, Jason Wang wrote:
> On 10/12/2014 05:27 PM, Michael S. Tsirkin wrote:
> > On Sat, Oct 11, 2014 at 03:16:44PM +0800, Jason Wang wrote:
> >> Below should be useful for some experiments Jason is doing.
> >> I thought I'd send it out for early review/feedback.
75 matches
Mail list logo
