Radim, Paolo, Sorry for the late responses (due to holidays)…
On Oct 11, 2014, at 12:39 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 10/10/2014 17:54, Radim Krčmář ha scritto:
One exception is the case of conforming code segment. The SDM says: Use a
code-segment override prefix (CS) to
Am 11.10.2014 um 09:14 hat Zhang Haoyu geschrieben:
In qcow2_update_snapshot_refcount - qcow2_process_discards() -
bdrv_discard()
may free the Qcow2DiscardRegion which is referenced by next pointer in
qcow2_process_discards() now, in next iteration, d = next, so g_free(d)
will double-free
On Sat, Oct 11, 2014 at 01:41:48AM -0600, Alex Williamson wrote:
On Sat, 2014-10-11 at 13:58 +0800, zhanghailiang wrote:
Hi all,
When i try to passthrough BCM5719 Gigabit Ethernet to guest using the qemu
master branch, it aborted,
and show kvm_set_phys_mem:error registering slot:Bad
On 2014-10-12 15:34, Kevin Wolf wrote:
Am 11.10.2014 um 09:14 hat Zhang Haoyu geschrieben:
In qcow2_update_snapshot_refcount - qcow2_process_discards() - bdrv_discard()
may free the Qcow2DiscardRegion which is referenced by next pointer in
qcow2_process_discards() now, in next iteration, d =
No kernel ever reported KVM_CAP_DEVICE_MSIX, KVM_CAP_DEVICE_MSI,
KVM_CAP_DEVICE_ASSIGNMENT, KVM_CAP_DEVICE_DEASSIGNMENT.
This makes the documentation wrong, and no application ever
written to use these capabilities has a chance to work correctly.
The only way to detect support is to try, and test
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.
event idx feature allows us to defer interrupts until
a specific # of descriptors were used.
Sometimes it might be
On Thu, Oct 09, 2014 at 08:41:23AM +0400, Dmitry Petuhov wrote:
From: Michael S. Tsirkin m...@redhat.com
upstream commit 23cc5a991c7a9fb7e6d6550e65cee4f4173111c5
Michael Mueller provided a patch to reduce the size of
vhost-net structure as some allocations could fail under
memory
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 m...@redhat.com
Acked-by: Cornelia Huck cornelia.h...@de.ibm.com
---
drivers/net/virtio_net.c | 6 ++
1 file changed, 2
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 m...@redhat.com
---
drivers/scsi/virtio_scsi.c | 23 +++
1 file changed, 7
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 m...@redhat.com
---
drivers/char/hw_random/virtio-rng.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git
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_enable_vqs_early before using VQ.
Signed-off-by: Michael
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 pbonz...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
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_enable_vqs_early before using VQs.
Signed-off-by:
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_enable_vqs_early before using VQs.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
From: Paolo Bonzini pbonz...@redhat.com
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 m...@redhat.com
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
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_enable_vqs_early before using VQs.
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_enable_vqs_early before
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_enable_vqs_early before using VQs.
Signed-off-by: Michael
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_enable_vqs_early before using event queue.
Signed-off-by: Michael S. Tsirkin
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_enable_vqs_early before using VQs.
Signed-off-by: Michael
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_enable_vqs_early before using VQs.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Reviewed-by:
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
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
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 m...@redhat.com
Reviewed-by: Cornelia Huck cornelia.h...@de.ibm.com
---
include/linux/virtio.h | 6 +
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
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
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 need to write unit tests for this, especially the conforming
case. A bit of a
I would like to install a simple system on the hardware level, and do most of
my work in one of the VM's.
In the past I have accessed VM's graphically using vnc, but if I did that my
base system (dom0 in Xen, I think) would need to run X server, which would
complicate it and render the whole
On Sun, 2014-10-12 at 18:21 +, Boylan, Ross wrote:
I would like to install a simple system on the hardware level, and do most of
my work in one of the VM's.
In the past I have accessed VM's graphically using vnc, but if I did that my
base system (dom0 in Xen, I think) would need to run X
Thanks for the info, and thanks also for working on the software.
It sounds as if the short answer is I can't do what I want with my current
hardware; am I understanding correcty? And to get it to work I need two video
cards? Do they both need to support the newer capabilities, or is it
https://bugzilla.kernel.org/show_bug.cgi?id=86161
Bug ID: 86161
Summary: PROBLEM: On KVM, Window 7 32bit guests sometimes run
into blue screen(0x005c) during reboot
Product: Virtualization
Version: unspecified
Kernel
Il 13/10/2014 01:15, Nadav Amit ha scritto:
I think the problem might be even more fundamental. According to the
SDM, the privilege level checks (CPL/DPL/RPL) are only performed when
the segment is loaded; I see no reference to privilege checks when
data is accessed. You should be able to load
35 matches
Mail list logo
