Re: [PATCH RFC 00/11] qemu: towards virtio-1 host support
On Tue, 28 Oct 2014 06:43:29 +0200 Michael S. Tsirkin m...@redhat.com wrote: On Fri, Oct 24, 2014 at 10:38:39AM +0200, Cornelia Huck wrote: On Fri, 24 Oct 2014 00:42:20 +0300 Michael S. Tsirkin m...@redhat.com wrote: On Tue, Oct 07, 2014 at 04:39:56PM +0200, Cornelia Huck wrote: This patchset aims to get us some way to implement virtio-1 compliant and transitional devices in qemu. Branch available at git://github.com/cohuck/qemu virtio-1 I've mainly focused on: - endianness handling - extended feature bits - virtio-ccw new/changed commands So issues identified so far: Thanks for taking a look. - devices not converted yet should not advertize 1.0 Neither should an uncoverted transport. So we either can - have transport set the bit and rely on devices -get_features callback to mask it out (virtio-ccw has to change the calling order for get_features, btw.) - have device set the bit and the transport mask it out later. Feels a bit weird, as virtio-1 is a transport feature bit. I thought more about it, I think the right thing would be for unconverted transports to clear high bits on ack and get features. This should work out of the box with my patches (virtio-pci and virtio-mmio return 0 for high feature bits). So bit 32 is set, but not exposed to guests. In fact at least for PCI, we have a 32 bit field for features in 0.9 so it's automatic. Didn't check mmio yet. We still to make sure the bit is not set for unconverted devices, though. But you're probably right that having the device set the bit is less error-prone. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC 00/11] qemu: towards virtio-1 host support
On Fri, Oct 24, 2014 at 10:38:39AM +0200, Cornelia Huck wrote:
On Fri, 24 Oct 2014 00:42:20 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Oct 07, 2014 at 04:39:56PM +0200, Cornelia Huck wrote:
This patchset aims to get us some way to implement virtio-1 compliant
and transitional devices in qemu. Branch available at
git://github.com/cohuck/qemu virtio-1
I've mainly focused on:
- endianness handling
- extended feature bits
- virtio-ccw new/changed commands
So issues identified so far:
Thanks for taking a look.
- devices not converted yet should not advertize 1.0
Neither should an uncoverted transport. So we either can
- have transport set the bit and rely on devices -get_features
callback to mask it out
(virtio-ccw has to change the calling order for get_features, btw.)
- have device set the bit and the transport mask it out later. Feels a
bit weird, as virtio-1 is a transport feature bit.
I thought more about it, I think the right thing
would be for unconverted transports to clear
high bits on ack and get features.
So bit 32 is set, but not exposed to guests.
In fact at least for PCI, we have a 32 bit field for
features in 0.9 so it's automatic.
Didn't check mmio yet.
I'm tending towards the first option; smth like this (on top of my
branch):
diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index c29c8c8..f6501ea 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -24,6 +24,9 @@
static uint32_t virtio_9p_get_features(VirtIODevice *vdev, unsigned int
index,
uint32_t features)
{
+if (index == 1) {
+features = ~(1 (VIRTIO_F_VERSION_1 - 32));
+}
if (index 0) {
return features;
}
diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 0d843fe..07a7a6f 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -472,6 +472,9 @@ static uint32_t get_features(VirtIODevice *vdev, unsigned
int index,
{
VirtIOSerial *vser;
+if (index == 1) {
+features = ~(1 (VIRTIO_F_VERSION_1 - 32));
+}
if (index 0) {
return features;
}
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 67f91c0..4b75105 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -447,6 +447,9 @@ static uint32_t virtio_net_get_features(VirtIODevice
*vdev, unsigned int index,
VirtIONet *n = VIRTIO_NET(vdev);
NetClientState *nc = qemu_get_queue(n-nic);
+if (index == 1 get_vhost_net(nc-peer)) {
+features = ~(1 (VIRTIO_F_VERSION_1 - 32));
+}
if (index 0) {
return features;
}
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index 80efe88..07fbf40 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -839,16 +839,16 @@ static int virtio_ccw_device_init(VirtioCcwDevice *dev,
VirtIODevice *vdev)
dev-revision = -1;
/* Set default feature bits that are offered by the host. */
+dev-host_features[0] = 0x1 VIRTIO_F_NOTIFY_ON_EMPTY;
+dev-host_features[0] |= 0x1 VIRTIO_F_BAD_FEATURE;
+
+dev-host_features[1] = 1 (VIRTIO_F_VERSION_1 - 32);
+
for (i = 0; i ARRAY_SIZE(dev-host_features); i++) {
dev-host_features[i] =
virtio_bus_get_vdev_features(dev-bus, i,
dev-host_features[i]);
}
-dev-host_features[0] |= 0x1 VIRTIO_F_NOTIFY_ON_EMPTY;
-dev-host_features[0] |= 0x1 VIRTIO_F_BAD_FEATURE;
-
-dev-host_features[1] = 1 (VIRTIO_F_VERSION_1 - 32);
-
css_generate_sch_crws(sch-cssid, sch-ssid, sch-schid,
parent-hotplugged, 1);
return 0;
diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c
index 8e1afa0..8a8fdb9 100644
--- a/hw/scsi/vhost-scsi.c
+++ b/hw/scsi/vhost-scsi.c
@@ -155,6 +155,9 @@ static uint32_t vhost_scsi_get_features(VirtIODevice
*vdev, unsigned int index,
{
VHostSCSI *s = VHOST_SCSI(vdev);
+if (index == 1) {
+features = ~(1 (VIRTIO_F_VERSION_1 - 32));
+}
if (index 0) {
return features;
}
diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
index 088e688..378783f 100644
--- a/hw/scsi/virtio-scsi.c
+++ b/hw/scsi/virtio-scsi.c
@@ -611,6 +611,9 @@ static void virtio_scsi_set_config(VirtIODevice *vdev,
static uint32_t virtio_scsi_get_features(VirtIODevice *vdev, unsigned int
index,
uint32_t requested_features)
{
+if (index == 1) {
+requested_features = ~(1 (VIRTIO_F_VERSION_1 - 32));
+}
return requested_features;
}
diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index 5af17e2..bd52845 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -306,6 +306,9 @@ static void virtio_balloon_set_config(VirtIODevice *vdev,
Re: [PATCH RFC 00/11] qemu: towards virtio-1 host support
On Fri, 24 Oct 2014 00:42:20 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Oct 07, 2014 at 04:39:56PM +0200, Cornelia Huck wrote:
This patchset aims to get us some way to implement virtio-1 compliant
and transitional devices in qemu. Branch available at
git://github.com/cohuck/qemu virtio-1
I've mainly focused on:
- endianness handling
- extended feature bits
- virtio-ccw new/changed commands
So issues identified so far:
Thanks for taking a look.
- devices not converted yet should not advertize 1.0
Neither should an uncoverted transport. So we either can
- have transport set the bit and rely on devices -get_features
callback to mask it out
(virtio-ccw has to change the calling order for get_features, btw.)
- have device set the bit and the transport mask it out later. Feels a
bit weird, as virtio-1 is a transport feature bit.
I'm tending towards the first option; smth like this (on top of my
branch):
diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index c29c8c8..f6501ea 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -24,6 +24,9 @@
static uint32_t virtio_9p_get_features(VirtIODevice *vdev, unsigned int index,
uint32_t features)
{
+if (index == 1) {
+features = ~(1 (VIRTIO_F_VERSION_1 - 32));
+}
if (index 0) {
return features;
}
diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 0d843fe..07a7a6f 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -472,6 +472,9 @@ static uint32_t get_features(VirtIODevice *vdev, unsigned
int index,
{
VirtIOSerial *vser;
+if (index == 1) {
+features = ~(1 (VIRTIO_F_VERSION_1 - 32));
+}
if (index 0) {
return features;
}
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 67f91c0..4b75105 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -447,6 +447,9 @@ static uint32_t virtio_net_get_features(VirtIODevice *vdev,
unsigned int index,
VirtIONet *n = VIRTIO_NET(vdev);
NetClientState *nc = qemu_get_queue(n-nic);
+if (index == 1 get_vhost_net(nc-peer)) {
+features = ~(1 (VIRTIO_F_VERSION_1 - 32));
+}
if (index 0) {
return features;
}
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index 80efe88..07fbf40 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -839,16 +839,16 @@ static int virtio_ccw_device_init(VirtioCcwDevice *dev,
VirtIODevice *vdev)
dev-revision = -1;
/* Set default feature bits that are offered by the host. */
+dev-host_features[0] = 0x1 VIRTIO_F_NOTIFY_ON_EMPTY;
+dev-host_features[0] |= 0x1 VIRTIO_F_BAD_FEATURE;
+
+dev-host_features[1] = 1 (VIRTIO_F_VERSION_1 - 32);
+
for (i = 0; i ARRAY_SIZE(dev-host_features); i++) {
dev-host_features[i] =
virtio_bus_get_vdev_features(dev-bus, i, dev-host_features[i]);
}
-dev-host_features[0] |= 0x1 VIRTIO_F_NOTIFY_ON_EMPTY;
-dev-host_features[0] |= 0x1 VIRTIO_F_BAD_FEATURE;
-
-dev-host_features[1] = 1 (VIRTIO_F_VERSION_1 - 32);
-
css_generate_sch_crws(sch-cssid, sch-ssid, sch-schid,
parent-hotplugged, 1);
return 0;
diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c
index 8e1afa0..8a8fdb9 100644
--- a/hw/scsi/vhost-scsi.c
+++ b/hw/scsi/vhost-scsi.c
@@ -155,6 +155,9 @@ static uint32_t vhost_scsi_get_features(VirtIODevice *vdev,
unsigned int index,
{
VHostSCSI *s = VHOST_SCSI(vdev);
+if (index == 1) {
+features = ~(1 (VIRTIO_F_VERSION_1 - 32));
+}
if (index 0) {
return features;
}
diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
index 088e688..378783f 100644
--- a/hw/scsi/virtio-scsi.c
+++ b/hw/scsi/virtio-scsi.c
@@ -611,6 +611,9 @@ static void virtio_scsi_set_config(VirtIODevice *vdev,
static uint32_t virtio_scsi_get_features(VirtIODevice *vdev, unsigned int
index,
uint32_t requested_features)
{
+if (index == 1) {
+requested_features = ~(1 (VIRTIO_F_VERSION_1 - 32));
+}
return requested_features;
}
diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index 5af17e2..bd52845 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -306,6 +306,9 @@ static void virtio_balloon_set_config(VirtIODevice *vdev,
static uint32_t virtio_balloon_get_features(VirtIODevice *vdev,
unsigned int index, uint32_t f)
{
+if (index == 1) {
+f = ~(1 (VIRTIO_F_VERSION_1 - 32));
+}
if (index 0) {
return f;
}
diff --git a/hw/virtio/virtio-rng.c b/hw/virtio/virtio-rng.c
index 2814017..bf6101d 100644
--- a/hw/virtio/virtio-rng.c
+++ b/hw/virtio/virtio-rng.c
@@ -101,6 +101,9 @@ static void handle_input(VirtIODevice *vdev, VirtQueue *vq)
Re: [PATCH RFC 00/11] qemu: towards virtio-1 host support
On Fri, 24 Oct 2014 10:38:39 +0200 Cornelia Huck cornelia.h...@de.ibm.com wrote: On Fri, 24 Oct 2014 00:42:20 +0300 Michael S. Tsirkin m...@redhat.com wrote: On Tue, Oct 07, 2014 at 04:39:56PM +0200, Cornelia Huck wrote: This patchset aims to get us some way to implement virtio-1 compliant and transitional devices in qemu. Branch available at git://github.com/cohuck/qemu virtio-1 I've mainly focused on: - endianness handling - extended feature bits - virtio-ccw new/changed commands So issues identified so far: Thanks for taking a look. - devices not converted yet should not advertize 1.0 Neither should an uncoverted transport. So we either can - have transport set the bit and rely on devices -get_features callback to mask it out (virtio-ccw has to change the calling order for get_features, btw.) - have device set the bit and the transport mask it out later. Feels a bit weird, as virtio-1 is a transport feature bit. I'm tending towards the first option; smth like this (on top of my branch): (...) OK, I played around with this patch on top and the vhost-next branch as guest. It seems to work reasonably well so far: a virtio-blk device used virtio-1, a virtio-balloon device legacy. One thing I noticed, though, is that I may need to think about virtio-ccw revision vs. virtio version again. As a device can refuse virtio-1 after the driver negotiated revision 1, we're operating a legacy device with (some) standard ccws. Probably not a big deal, as (a) both driver and device already have indicated that they support revision 1 which those ccws are tied to and (b) some legacy devices/drivers already support standard ccws (adapter interrupt support). I might want to clarify the standard a bit, let me think about that over the weekend. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC 00/11] qemu: towards virtio-1 host support
On Fri, Oct 24, 2014 at 02:37:08PM +0200, Cornelia Huck wrote: On Fri, 24 Oct 2014 10:38:39 +0200 Cornelia Huck cornelia.h...@de.ibm.com wrote: On Fri, 24 Oct 2014 00:42:20 +0300 Michael S. Tsirkin m...@redhat.com wrote: On Tue, Oct 07, 2014 at 04:39:56PM +0200, Cornelia Huck wrote: This patchset aims to get us some way to implement virtio-1 compliant and transitional devices in qemu. Branch available at git://github.com/cohuck/qemu virtio-1 I've mainly focused on: - endianness handling - extended feature bits - virtio-ccw new/changed commands So issues identified so far: Thanks for taking a look. - devices not converted yet should not advertize 1.0 Neither should an uncoverted transport. So we either can - have transport set the bit and rely on devices -get_features callback to mask it out (virtio-ccw has to change the calling order for get_features, btw.) - have device set the bit and the transport mask it out later. Feels a bit weird, as virtio-1 is a transport feature bit. I'm tending towards the first option; smth like this (on top of my branch): (...) OK, I played around with this patch on top and the vhost-next branch as guest. It seems to work reasonably well so far: a virtio-blk device used virtio-1, a virtio-balloon device legacy. One thing I noticed, though, is that I may need to think about virtio-ccw revision vs. virtio version again. As a device can refuse virtio-1 after the driver negotiated revision 1, we're operating a legacy device with (some) standard ccws. Probably not a big deal, as (a) both driver and device already have indicated that they support revision 1 which those ccws are tied to and (b) some legacy devices/drivers already support standard ccws (adapter interrupt support). I might want to clarify the standard a bit, let me think about that over the weekend. Thanks! Please note I have updated the branch several times - I'm not going to send patches until next week. I updated vhost net by now. Just for the kernel, host side, we need to update tun, macvtap, af_packet, vhost scsi and vhost test. Guest side, we need to keep going over devices and convert them one by one. And of course qemu, including support for old and new tun/macvtap. -- MST ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC 00/11] qemu: towards virtio-1 host support
On Fri, Oct 24, 2014 at 10:38:39AM +0200, Cornelia Huck wrote:
On Fri, 24 Oct 2014 00:42:20 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Oct 07, 2014 at 04:39:56PM +0200, Cornelia Huck wrote:
This patchset aims to get us some way to implement virtio-1 compliant
and transitional devices in qemu. Branch available at
git://github.com/cohuck/qemu virtio-1
I've mainly focused on:
- endianness handling
- extended feature bits
- virtio-ccw new/changed commands
So issues identified so far:
Thanks for taking a look.
- devices not converted yet should not advertize 1.0
Neither should an uncoverted transport. So we either can
- have transport set the bit and rely on devices -get_features
callback to mask it out
(virtio-ccw has to change the calling order for get_features, btw.)
- have device set the bit and the transport mask it out later. Feels a
bit weird, as virtio-1 is a transport feature bit.
I'm tending towards the first option; smth like this (on top of my
branch):
I would rather *converted* devices had extra code
than unconverted ones.
Reduces the chance we forget one by mistake.
diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index c29c8c8..f6501ea 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -24,6 +24,9 @@
static uint32_t virtio_9p_get_features(VirtIODevice *vdev, unsigned int
index,
uint32_t features)
{
+if (index == 1) {
+features = ~(1 (VIRTIO_F_VERSION_1 - 32));
+}
if (index 0) {
return features;
}
diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 0d843fe..07a7a6f 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -472,6 +472,9 @@ static uint32_t get_features(VirtIODevice *vdev, unsigned
int index,
{
VirtIOSerial *vser;
+if (index == 1) {
+features = ~(1 (VIRTIO_F_VERSION_1 - 32));
+}
if (index 0) {
return features;
}
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 67f91c0..4b75105 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -447,6 +447,9 @@ static uint32_t virtio_net_get_features(VirtIODevice
*vdev, unsigned int index,
VirtIONet *n = VIRTIO_NET(vdev);
NetClientState *nc = qemu_get_queue(n-nic);
+if (index == 1 get_vhost_net(nc-peer)) {
+features = ~(1 (VIRTIO_F_VERSION_1 - 32));
+}
if (index 0) {
return features;
}
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index 80efe88..07fbf40 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -839,16 +839,16 @@ static int virtio_ccw_device_init(VirtioCcwDevice *dev,
VirtIODevice *vdev)
dev-revision = -1;
/* Set default feature bits that are offered by the host. */
+dev-host_features[0] = 0x1 VIRTIO_F_NOTIFY_ON_EMPTY;
+dev-host_features[0] |= 0x1 VIRTIO_F_BAD_FEATURE;
+
+dev-host_features[1] = 1 (VIRTIO_F_VERSION_1 - 32);
+
for (i = 0; i ARRAY_SIZE(dev-host_features); i++) {
dev-host_features[i] =
virtio_bus_get_vdev_features(dev-bus, i,
dev-host_features[i]);
}
-dev-host_features[0] |= 0x1 VIRTIO_F_NOTIFY_ON_EMPTY;
-dev-host_features[0] |= 0x1 VIRTIO_F_BAD_FEATURE;
-
-dev-host_features[1] = 1 (VIRTIO_F_VERSION_1 - 32);
-
css_generate_sch_crws(sch-cssid, sch-ssid, sch-schid,
parent-hotplugged, 1);
return 0;
diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c
index 8e1afa0..8a8fdb9 100644
--- a/hw/scsi/vhost-scsi.c
+++ b/hw/scsi/vhost-scsi.c
@@ -155,6 +155,9 @@ static uint32_t vhost_scsi_get_features(VirtIODevice
*vdev, unsigned int index,
{
VHostSCSI *s = VHOST_SCSI(vdev);
+if (index == 1) {
+features = ~(1 (VIRTIO_F_VERSION_1 - 32));
+}
if (index 0) {
return features;
}
diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
index 088e688..378783f 100644
--- a/hw/scsi/virtio-scsi.c
+++ b/hw/scsi/virtio-scsi.c
@@ -611,6 +611,9 @@ static void virtio_scsi_set_config(VirtIODevice *vdev,
static uint32_t virtio_scsi_get_features(VirtIODevice *vdev, unsigned int
index,
uint32_t requested_features)
{
+if (index == 1) {
+requested_features = ~(1 (VIRTIO_F_VERSION_1 - 32));
+}
return requested_features;
}
diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index 5af17e2..bd52845 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -306,6 +306,9 @@ static void virtio_balloon_set_config(VirtIODevice *vdev,
static uint32_t virtio_balloon_get_features(VirtIODevice *vdev,
unsigned int index, uint32_t f)
{
+if (index == 1) {
+
Re: [PATCH RFC 00/11] qemu: towards virtio-1 host support
On 2014-10-22 22:34, Benjamin Herrenschmidt wrote: On Wed, 2014-10-22 at 16:17 +0200, Jan Kiszka wrote: I thought about this again, and I'm not sure anymore if we can use ACPI to black-list the incompatible virtio devices. Reason: hotplug. To my understanding, the ACPI DRHD tables won't change during runtime when a device shows up or disappears. We would have to isolate virtio devices from the rest of the system by using separate buses for it (and avoid listing those in any DRHD table) and enforce that they only get plugged into those buses. I suppose that is not desirable. Maybe it's better to fix virtio /wrt IOMMUs. I always go back to my initial proposal which is to define that current virtio always bypass any iommu (which is what it does really) and have it expose via a new capability if that isn't the case. That means fixing that Xen thingy to allow qemu to know what to expose I assume but that seems to be the less bad approach. Just one thing to consider: feature negotiation happens after guest startup. If we run a virtio device under IOMMU control, what will we have to do when the guest says it does not support such devices? Simply reject operation? Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC 00/11] qemu: towards virtio-1 host support
On Thu, Oct 23, 2014 at 07:34:16AM +1100, Benjamin Herrenschmidt wrote: On Wed, 2014-10-22 at 16:17 +0200, Jan Kiszka wrote: I thought about this again, and I'm not sure anymore if we can use ACPI to black-list the incompatible virtio devices. Reason: hotplug. To my understanding, the ACPI DRHD tables won't change during runtime when a device shows up or disappears. We would have to isolate virtio devices from the rest of the system by using separate buses for it (and avoid listing those in any DRHD table) and enforce that they only get plugged into those buses. I suppose that is not desirable. Maybe it's better to fix virtio /wrt IOMMUs. I always go back to my initial proposal which is to define that current virtio always bypass any iommu (which is what it does really) and have it expose via a new capability if that isn't the case. That means fixing that Xen thingy to allow qemu to know what to expose I assume but that seems to be the less bad approach. Cheers, Ben. OK so how does this work? If you want to run an existing guest, you use the old device. And presumably you blacklist virtio for nested virt then, unless a new capability is present? -- MST ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC 00/11] qemu: towards virtio-1 host support
On Thu, Oct 23, 2014 at 08:44:09AM +0200, Jan Kiszka wrote: On 2014-10-22 22:34, Benjamin Herrenschmidt wrote: On Wed, 2014-10-22 at 16:17 +0200, Jan Kiszka wrote: I thought about this again, and I'm not sure anymore if we can use ACPI to black-list the incompatible virtio devices. Reason: hotplug. To my understanding, the ACPI DRHD tables won't change during runtime when a device shows up or disappears. We would have to isolate virtio devices from the rest of the system by using separate buses for it (and avoid listing those in any DRHD table) and enforce that they only get plugged into those buses. I suppose that is not desirable. Maybe it's better to fix virtio /wrt IOMMUs. I always go back to my initial proposal which is to define that current virtio always bypass any iommu (which is what it does really) and have it expose via a new capability if that isn't the case. That means fixing that Xen thingy to allow qemu to know what to expose I assume but that seems to be the less bad approach. Just one thing to consider: feature negotiation happens after guest startup. If we run a virtio device under IOMMU control, what will we have to do when the guest says it does not support such devices? Simply reject operation? Jan We could restrict this to the new set of device IDs that got introduced in virtio 1.0. That actually has a mechanism for devices to gracefully reject a combination of features if we still need it. -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC 00/11] qemu: towards virtio-1 host support
On Tue, Oct 07, 2014 at 04:39:56PM +0200, Cornelia Huck wrote: This patchset aims to get us some way to implement virtio-1 compliant and transitional devices in qemu. Branch available at git://github.com/cohuck/qemu virtio-1 I've mainly focused on: - endianness handling - extended feature bits - virtio-ccw new/changed commands So issues identified so far: - devices not converted yet should not advertize 1.0 - blk has some features removed under 1.0, specifically CONFIG_WCE. - net header is different for 1.0 Thanks go to Thomas for some preliminary work in this area. I've been able to start guests both with and without the virtio-1 patches in the linux guest patchset, with virtio-net and virtio-blk devices (with and without dataplane). virtio-ccw only :) vhost, migration and loads of other things have been ignored for now. I'd like to know whether I walk into the right direction, so let's consider this as a starting point. Cornelia Huck (8): virtio: cull virtio_bus_set_vdev_features virtio: support more feature bits s390x/virtio-ccw: fix check for WRITE_FEAT virtio: introduce legacy virtio devices virtio: allow virtio-1 queue layout dataplane: allow virtio-1 devices s390x/virtio-ccw: support virtio-1 set_vq format s390x/virtio-ccw: enable virtio 1.0 Thomas Huth (3): linux-headers/virtio_config: Update with VIRTIO_F_VERSION_1 s390x/css: Add a callback for when subchannel gets disabled s390x/virtio-ccw: add virtio set-revision call hw/9pfs/virtio-9p-device.c |7 +- hw/block/dataplane/virtio-blk.c |3 +- hw/block/virtio-blk.c |9 +- hw/char/virtio-serial-bus.c |9 +- hw/net/virtio-net.c | 38 --- hw/s390x/css.c | 12 +++ hw/s390x/css.h |1 + hw/s390x/s390-virtio-bus.c |9 +- hw/s390x/virtio-ccw.c | 188 +++ hw/s390x/virtio-ccw.h |7 +- hw/scsi/vhost-scsi.c|7 +- hw/scsi/virtio-scsi-dataplane.c |2 +- hw/scsi/virtio-scsi.c |8 +- hw/virtio/Makefile.objs |2 +- hw/virtio/dataplane/Makefile.objs |2 +- hw/virtio/dataplane/vring.c | 95 ++ hw/virtio/virtio-balloon.c |8 +- hw/virtio/virtio-bus.c | 23 + hw/virtio/virtio-mmio.c |9 +- hw/virtio/virtio-pci.c | 13 +-- hw/virtio/virtio-rng.c |2 +- hw/virtio/virtio.c | 51 +++--- include/hw/virtio/dataplane/vring.h | 64 +++- include/hw/virtio/virtio-access.h |4 + include/hw/virtio/virtio-bus.h | 10 +- include/hw/virtio/virtio.h | 34 +-- linux-headers/linux/virtio_config.h |3 + 27 files changed, 442 insertions(+), 178 deletions(-) -- 1.7.9.5 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC 00/11] qemu: towards virtio-1 host support
On Wed, Oct 08, 2014 at 11:04:28AM +0200, Cornelia Huck wrote: On Tue, 07 Oct 2014 18:24:22 -0700 Andy Lutomirski l...@amacapital.net wrote: On 10/07/2014 07:39 AM, Cornelia Huck wrote: This patchset aims to get us some way to implement virtio-1 compliant and transitional devices in qemu. Branch available at git://github.com/cohuck/qemu virtio-1 I've mainly focused on: - endianness handling - extended feature bits - virtio-ccw new/changed commands At the risk of some distraction, would it be worth thinking about a solution to the IOMMU bypassing mess as part of this? I think that is a whole different issue. virtio-1 is basically done - we just need to implement it - while the IOMMU/DMA stuff certainly needs more discussion. Therefore, I'd like to defer to the other discussion thread here. I agree, let's do a separate thread for this. I also think it's up to the hypervisors at this point. People talked about using ACPI to report IOMMU bypass to guest. If that happens, we don't need a feature bit. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC 00/11] qemu: towards virtio-1 host support
On 2014-10-22 10:44, Michael S. Tsirkin wrote: On Wed, Oct 08, 2014 at 11:04:28AM +0200, Cornelia Huck wrote: On Tue, 07 Oct 2014 18:24:22 -0700 Andy Lutomirski l...@amacapital.net wrote: On 10/07/2014 07:39 AM, Cornelia Huck wrote: This patchset aims to get us some way to implement virtio-1 compliant and transitional devices in qemu. Branch available at git://github.com/cohuck/qemu virtio-1 I've mainly focused on: - endianness handling - extended feature bits - virtio-ccw new/changed commands At the risk of some distraction, would it be worth thinking about a solution to the IOMMU bypassing mess as part of this? I think that is a whole different issue. virtio-1 is basically done - we just need to implement it - while the IOMMU/DMA stuff certainly needs more discussion. Therefore, I'd like to defer to the other discussion thread here. I agree, let's do a separate thread for this. I also think it's up to the hypervisors at this point. People talked about using ACPI to report IOMMU bypass to guest. If that happens, we don't need a feature bit. I thought about this again, and I'm not sure anymore if we can use ACPI to black-list the incompatible virtio devices. Reason: hotplug. To my understanding, the ACPI DRHD tables won't change during runtime when a device shows up or disappears. We would have to isolate virtio devices from the rest of the system by using separate buses for it (and avoid listing those in any DRHD table) and enforce that they only get plugged into those buses. I suppose that is not desirable. Maybe it's better to fix virtio /wrt IOMMUs. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC 00/11] qemu: towards virtio-1 host support
On Wed, Oct 22, 2014 at 04:17:40PM +0200, Jan Kiszka wrote: On 2014-10-22 10:44, Michael S. Tsirkin wrote: On Wed, Oct 08, 2014 at 11:04:28AM +0200, Cornelia Huck wrote: On Tue, 07 Oct 2014 18:24:22 -0700 Andy Lutomirski l...@amacapital.net wrote: On 10/07/2014 07:39 AM, Cornelia Huck wrote: This patchset aims to get us some way to implement virtio-1 compliant and transitional devices in qemu. Branch available at git://github.com/cohuck/qemu virtio-1 I've mainly focused on: - endianness handling - extended feature bits - virtio-ccw new/changed commands At the risk of some distraction, would it be worth thinking about a solution to the IOMMU bypassing mess as part of this? I think that is a whole different issue. virtio-1 is basically done - we just need to implement it - while the IOMMU/DMA stuff certainly needs more discussion. Therefore, I'd like to defer to the other discussion thread here. I agree, let's do a separate thread for this. I also think it's up to the hypervisors at this point. People talked about using ACPI to report IOMMU bypass to guest. If that happens, we don't need a feature bit. I thought about this again, and I'm not sure anymore if we can use ACPI to black-list the incompatible virtio devices. Reason: hotplug. To my understanding, the ACPI DRHD tables won't change during runtime when a device shows up or disappears. We would have to isolate virtio devices from the rest of the system by using separate buses for it (and avoid listing those in any DRHD table) and enforce that they only get plugged into those buses. I suppose that is not desirable. That's reasonable I think. Maybe it's better to fix virtio /wrt IOMMUs. Jan Yes but this seems unlikely for 2.2: The wish to run old guests with iommu remains. So we'll need to support iommu bypass on the host, and so as a minimum new guest needs to detect such bypass host and fail. Unrelated: we also need to teach vhost and dataplane virtio to get mappings from the iommu. -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC 00/11] qemu: towards virtio-1 host support
On Wed, 2014-10-22 at 16:17 +0200, Jan Kiszka wrote: I thought about this again, and I'm not sure anymore if we can use ACPI to black-list the incompatible virtio devices. Reason: hotplug. To my understanding, the ACPI DRHD tables won't change during runtime when a device shows up or disappears. We would have to isolate virtio devices from the rest of the system by using separate buses for it (and avoid listing those in any DRHD table) and enforce that they only get plugged into those buses. I suppose that is not desirable. Maybe it's better to fix virtio /wrt IOMMUs. I always go back to my initial proposal which is to define that current virtio always bypass any iommu (which is what it does really) and have it expose via a new capability if that isn't the case. That means fixing that Xen thingy to allow qemu to know what to expose I assume but that seems to be the less bad approach. Cheers, Ben. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC 00/11] qemu: towards virtio-1 host support
On Tue, 07 Oct 2014 18:24:22 -0700 Andy Lutomirski l...@amacapital.net wrote: On 10/07/2014 07:39 AM, Cornelia Huck wrote: This patchset aims to get us some way to implement virtio-1 compliant and transitional devices in qemu. Branch available at git://github.com/cohuck/qemu virtio-1 I've mainly focused on: - endianness handling - extended feature bits - virtio-ccw new/changed commands At the risk of some distraction, would it be worth thinking about a solution to the IOMMU bypassing mess as part of this? I think that is a whole different issue. virtio-1 is basically done - we just need to implement it - while the IOMMU/DMA stuff certainly needs more discussion. Therefore, I'd like to defer to the other discussion thread here. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH RFC 00/11] qemu: towards virtio-1 host support
This patchset aims to get us some way to implement virtio-1 compliant and transitional devices in qemu. Branch available at git://github.com/cohuck/qemu virtio-1 I've mainly focused on: - endianness handling - extended feature bits - virtio-ccw new/changed commands Thanks go to Thomas for some preliminary work in this area. I've been able to start guests both with and without the virtio-1 patches in the linux guest patchset, with virtio-net and virtio-blk devices (with and without dataplane). virtio-ccw only :) vhost, migration and loads of other things have been ignored for now. I'd like to know whether I walk into the right direction, so let's consider this as a starting point. Cornelia Huck (8): virtio: cull virtio_bus_set_vdev_features virtio: support more feature bits s390x/virtio-ccw: fix check for WRITE_FEAT virtio: introduce legacy virtio devices virtio: allow virtio-1 queue layout dataplane: allow virtio-1 devices s390x/virtio-ccw: support virtio-1 set_vq format s390x/virtio-ccw: enable virtio 1.0 Thomas Huth (3): linux-headers/virtio_config: Update with VIRTIO_F_VERSION_1 s390x/css: Add a callback for when subchannel gets disabled s390x/virtio-ccw: add virtio set-revision call hw/9pfs/virtio-9p-device.c |7 +- hw/block/dataplane/virtio-blk.c |3 +- hw/block/virtio-blk.c |9 +- hw/char/virtio-serial-bus.c |9 +- hw/net/virtio-net.c | 38 --- hw/s390x/css.c | 12 +++ hw/s390x/css.h |1 + hw/s390x/s390-virtio-bus.c |9 +- hw/s390x/virtio-ccw.c | 188 +++ hw/s390x/virtio-ccw.h |7 +- hw/scsi/vhost-scsi.c|7 +- hw/scsi/virtio-scsi-dataplane.c |2 +- hw/scsi/virtio-scsi.c |8 +- hw/virtio/Makefile.objs |2 +- hw/virtio/dataplane/Makefile.objs |2 +- hw/virtio/dataplane/vring.c | 95 ++ hw/virtio/virtio-balloon.c |8 +- hw/virtio/virtio-bus.c | 23 + hw/virtio/virtio-mmio.c |9 +- hw/virtio/virtio-pci.c | 13 +-- hw/virtio/virtio-rng.c |2 +- hw/virtio/virtio.c | 51 +++--- include/hw/virtio/dataplane/vring.h | 64 +++- include/hw/virtio/virtio-access.h |4 + include/hw/virtio/virtio-bus.h | 10 +- include/hw/virtio/virtio.h | 34 +-- linux-headers/linux/virtio_config.h |3 + 27 files changed, 442 insertions(+), 178 deletions(-) -- 1.7.9.5 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC 00/11] qemu: towards virtio-1 host support
On 10/07/2014 07:39 AM, Cornelia Huck wrote: This patchset aims to get us some way to implement virtio-1 compliant and transitional devices in qemu. Branch available at git://github.com/cohuck/qemu virtio-1 I've mainly focused on: - endianness handling - extended feature bits - virtio-ccw new/changed commands At the risk of some distraction, would it be worth thinking about a solution to the IOMMU bypassing mess as part of this? --Andy ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
