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 v4 07/17] virtio_config: endian conversion for v1.0
On Thu, 23 Oct 2014 19:24:30 +0300 Michael S. Tsirkin m...@redhat.com wrote: We (ab)use virtio conversion functions for device-specific config space accesses. Reviewed-by: David Hildenbrand d...@linux.vnet.ibm.com Signed-off-by: Rusty Russell ru...@rustcorp.com.au Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com Signed-off-by: Michael S. Tsirkin m...@redhat.com --- include/linux/virtio_config.h | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) Not objecting to the patch, but something seems to have gotten messed up wrt authorship? You only adapted it, right? ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v12 09/11] pvqspinlock, x86: Add para-virtualization support
On Thu, Oct 16, 2014 at 02:10:38PM -0400, Waiman Long wrote:
Since enabling paravirt spinlock will disable unlock function inlining,
a jump label can be added to the unlock function without adding patch
sites all over the kernel.
But you don't have to. My patches allowed for the inline to remain,
again reducing the overhead of enabling PV spinlocks while running on a
real machine.
Look at:
http://lkml.kernel.org/r/20140615130154.213923...@chello.nl
In particular this hunk:
Index: linux-2.6/arch/x86/kernel/paravirt_patch_64.c
===
--- linux-2.6.orig/arch/x86/kernel/paravirt_patch_64.c
+++ linux-2.6/arch/x86/kernel/paravirt_patch_64.c
@@ -22,6 +22,10 @@ DEF_NATIVE(pv_cpu_ops, swapgs, swapgs)
DEF_NATIVE(, mov32, mov %edi, %eax);
DEF_NATIVE(, mov64, mov %rdi, %rax);
+#if defined(CONFIG_PARAVIRT_SPINLOCKS) defined(CONFIG_QUEUE_SPINLOCK)
+DEF_NATIVE(pv_lock_ops, queue_unlock, movb $0, (%rdi));
+#endif
+
unsigned paravirt_patch_ident_32(void *insnbuf, unsigned len)
{
return paravirt_patch_insns(insnbuf, len,
@@ -61,6 +65,9 @@ unsigned native_patch(u8 type, u16 clobb
PATCH_SITE(pv_cpu_ops, clts);
PATCH_SITE(pv_mmu_ops, flush_tlb_single);
PATCH_SITE(pv_cpu_ops, wbinvd);
+#if defined(CONFIG_PARAVIRT_SPINLOCKS) defined(CONFIG_QUEUE_SPINLOCK)
+ PATCH_SITE(pv_lock_ops, queue_unlock);
+#endif
patch_site:
ret = paravirt_patch_insns(ibuf, len, start, end);
That makes sure to overwrite the callee-saved call to the
pv_lock_ops::queue_unlock with the immediate asm movb $0, (%rdi).
Therefore you can retain the inlined unlock with hardly (there might be
some NOP padding) any overhead at all. On PV it reverts to a callee
saved function call.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v12 00/11] qspinlock: a 4-byte queue spinlock with PV support
On Thu, Oct 16, 2014 at 02:10:29PM -0400, Waiman Long wrote: v11-v12: - Based on PeterZ's version of the qspinlock patch (https://lkml.org/lkml/2014/6/15/63). - Incorporated many of the review comments from Konrad Wilk and Paolo Bonzini. - The pvqspinlock code is largely from my previous version with PeterZ's way of going from queue tail to head and his idea of using callee saved calls to KVM and XEN codes. Thanks for taking the time to refresh this.. I would prefer you use a little more of the PV techniques I outlined in my latest PV patch to further reduce the overhead of PV enabled kernels on real hardware. This is an important use case, because distro kernels will have to enable PV support while their majority of installations will be on physical hardware. Other than that I see no reason not to move this forward. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v12 09/11] pvqspinlock, x86: Add para-virtualization support
On Thu, Oct 16, 2014 at 02:10:38PM -0400, Waiman Long wrote:
+static inline void pv_init_node(struct mcs_spinlock *node)
+{
+ struct pv_qnode *pn = (struct pv_qnode *)node;
+
+ BUILD_BUG_ON(sizeof(struct pv_qnode) 5*sizeof(struct mcs_spinlock));
+
+ if (!pv_enabled())
+ return;
+
+ pn-cpustate = PV_CPU_ACTIVE;
+ pn-mayhalt = false;
+ pn-mycpu= smp_processor_id();
+ pn-head = PV_INVALID_HEAD;
+}
@@ -333,6 +393,7 @@ queue:
node += idx;
node-locked = 0;
node-next = NULL;
+ pv_init_node(node);
/*
* We touched a (possibly) cold cacheline in the per-cpu queue node;
So even if !pv_enabled() the compiler will still have to emit the code
for that inline, which will generate additional register pressure,
icache pressure and lovely stuff like that.
The patch I had used pv-ops for these things that would turn into NOPs
in the regular case and callee-saved function calls for the PV case.
That still does not entirely eliminate cost, but does reduce it
significant. Please consider using that.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
RE: [PATCH RFC 1/4] virtio_net: pass vi around
From: Michael S. Tsirkin
Too many places poke at [rs]q-vq-vdev-priv just to get
the the vi structure. Let's just pass the pointer around: seems
cleaner, and might even be faster.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/net/virtio_net.c | 36 +++-
1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 57cbc7d..36f3dfc 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
...
static struct sk_buff *receive_big(struct net_device *dev,
+struct virtnet_info *vi,
Do you need to pass 'dev' here?
Looks like it is obtainable from vi-dev (as below).
David
struct receive_queue *rq,
void *buf,
unsigned int len)
{
struct page *page = buf;
- struct sk_buff *skb = page_to_skb(rq, page, 0, len, PAGE_SIZE);
+ struct sk_buff *skb = page_to_skb(vi, rq, page, 0, len, PAGE_SIZE);
...
-static void receive_buf(struct receive_queue *rq, void *buf, unsigned int
len)
+static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq,
+ void *buf, unsigned int len)
{
- struct virtnet_info *vi = rq-vq-vdev-priv;
struct net_device *dev = vi-dev;
...
___
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, 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 v4 07/17] virtio_config: endian conversion for v1.0
On Fri, Oct 24, 2014 at 10:53:27AM +0200, Cornelia Huck wrote: On Thu, 23 Oct 2014 19:24:30 +0300 Michael S. Tsirkin m...@redhat.com wrote: We (ab)use virtio conversion functions for device-specific config space accesses. Reviewed-by: David Hildenbrand d...@linux.vnet.ibm.com Signed-off-by: Rusty Russell ru...@rustcorp.com.au Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com Signed-off-by: Michael S. Tsirkin m...@redhat.com --- include/linux/virtio_config.h | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) Not objecting to the patch, but something seems to have gotten messed up wrt authorship? You only adapted it, right? I'll change author to Rusty. ___ 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 1/4] virtio_net: pass vi around
On Fri, Oct 24, 2014 at 10:02:15AM +, David Laight wrote:
From: Michael S. Tsirkin
Too many places poke at [rs]q-vq-vdev-priv just to get
the the vi structure. Let's just pass the pointer around: seems
cleaner, and might even be faster.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/net/virtio_net.c | 36 +++-
1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 57cbc7d..36f3dfc 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
...
static struct sk_buff *receive_big(struct net_device *dev,
+ struct virtnet_info *vi,
Do you need to pass 'dev' here?
Looks like it is obtainable from vi-dev (as below).
David
struct receive_queue *rq,
void *buf,
unsigned int len)
{
struct page *page = buf;
- struct sk_buff *skb = page_to_skb(rq, page, 0, len, PAGE_SIZE);
+ struct sk_buff *skb = page_to_skb(vi, rq, page, 0, len, PAGE_SIZE);
...
-static void receive_buf(struct receive_queue *rq, void *buf, unsigned int
len)
+static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq,
+ void *buf, unsigned int len)
{
- struct virtnet_info *vi = rq-vq-vdev-priv;
struct net_device *dev = vi-dev;
...
It's a matter of style, isn't it?
We have dev to hand, it seems cleaner to just pass it around.
--
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: v3.18-rc1 32 bit KVM hangs early in boot process
On 10/21/2014 06:40 PM, Josh Boyer wrote: On Tue, Oct 21, 2014 at 12:10 PM, Toralf Förster toralf.foers...@gmx.de wrote: On 10/20/2014 07:34 PM, Toralf Förster wrote: I uploaded the screen shots from the virt-manager to [1] and [2] FWIW e56d9fccb was fine so the bug slipped in after that. [1] http://www.directupload.net/file/d/3781/j9mwrtpq_jpg.htm [2] http://www.directupload.net/file/d/3781/29trc56v_jpg.htm It might be virtio-console related, when the uevetns are processed: http://www.directupload.net/file/d/3782/6lg5yihh_jpg.htm Try http://mid.gmane.org/1413813529-11044-1-git-send-email-cornelia.h...@de.ibm.com josh I just reverted $ grep commit virtcons_* virtcons_1.patch:commit f5866db64f341776c2d9ed48080f82459fea6a55 virtcons_2.patch:commit 401bbdc901b268113d7c562616feb7fc37492aca on top of -rc1 which solved the issue entirely here. -- Toralf pgp key: 0076 E94E ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: v3.18-rc1 32 bit KVM hangs early in boot process
On 10/24/2014 05:44 PM, Toralf Förster wrote: I just reverted $ grep commit virtcons_* virtcons_1.patch:commit f5866db64f341776c2d9ed48080f82459fea6a55 virtcons_2.patch:commit 401bbdc901b268113d7c562616feb7fc37492aca on top of -rc1 which solved the issue entirely here. (but I had to disable autitd, b/c otherwise the boot of the 32 bit Gentoo KVM would hang during start of auditd (installed version 2.2.2) -- Toralf pgp key: 0076 E94E ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v12 09/11] pvqspinlock, x86: Add para-virtualization support
On 10/24/2014 04:47 AM, Peter Zijlstra wrote:
On Thu, Oct 16, 2014 at 02:10:38PM -0400, Waiman Long wrote:
+static inline void pv_init_node(struct mcs_spinlock *node)
+{
+ struct pv_qnode *pn = (struct pv_qnode *)node;
+
+ BUILD_BUG_ON(sizeof(struct pv_qnode) 5*sizeof(struct mcs_spinlock));
+
+ if (!pv_enabled())
+ return;
+
+ pn-cpustate = PV_CPU_ACTIVE;
+ pn-mayhalt = false;
+ pn-mycpu= smp_processor_id();
+ pn-head = PV_INVALID_HEAD;
+}
@@ -333,6 +393,7 @@ queue:
node += idx;
node-locked = 0;
node-next = NULL;
+ pv_init_node(node);
/*
* We touched a (possibly) cold cacheline in the per-cpu queue node;
So even if !pv_enabled() the compiler will still have to emit the code
for that inline, which will generate additional register pressure,
icache pressure and lovely stuff like that.
The patch I had used pv-ops for these things that would turn into NOPs
in the regular case and callee-saved function calls for the PV case.
That still does not entirely eliminate cost, but does reduce it
significant. Please consider using that.
The additional register pressure may just cause a few more register
moves which should be negligible in the overall performance . The
additional icache pressure, however, may have some impact on
performance. I was trying to balance the performance of the pv and
non-pv versions so that we won't penalize the pv code too much for a bit
more performance in the non-pv code. Doing it your way will add a lot of
function call and register saving/restoring to the pv code.
Another alternative that I can think of is to generate 2 versions of the
slowpath code - one pv and one non-pv out of the same source code. The
non-pv code will call into the pv code once if pv is enabled. In this
way, it won't increase the icache and register pressure of the non-pv
code. However, this may make the source code a bit harder to read.
Please let me know your thought on this alternate approach.
-Longman
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v12 09/11] pvqspinlock, x86: Add para-virtualization support
On Fri, Oct 24, 2014 at 04:53:27PM -0400, Waiman Long wrote: The additional register pressure may just cause a few more register moves which should be negligible in the overall performance . The additional icache pressure, however, may have some impact on performance. I was trying to balance the performance of the pv and non-pv versions so that we won't penalize the pv code too much for a bit more performance in the non-pv code. Doing it your way will add a lot of function call and register saving/restoring to the pv code. If people care about performance they should not be using virt crap :-) I only really care about bare metal. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
CFP: IEEE Cluster 2015 -- Chicago IL September 8-11 2015
IEEE International Conference on Cluster Computing September 8-11, 2015 Chicago, IL, USA https://press3.mcs.anl.gov/ieeecluster2015/ -- ...Follow us on Facebook athttps://www.facebook.com/ieee.cluster ...Follow us on Twitter athttps://twitter.com/IEEECluster ...Follow us on Linkedin at https://www.linkedin.com/groups/IEEE-International-Conference-on-Cluster-7428925 ...Follow us on RenRen athttp://page.renren.com/601871401 -- CALL FOR PAPERS Following the successes of the series of Cluster conferences, for 2015 we solicit high-quality original papers presenting work that advances the state-of-the-art in clusters and closely related fields. All papers will be rigorously peer-reviewed for their originality, technical depth and correctness, potential impact, relevance to the conference, and quality of presentation. Research papers must clearly demonstrate research contributions and novelty, while papers reporting experience must clearly describe lessons learned and impact, along with the utility of the approach compared to the ones in the past. PAPER TRACKS * Applications, Algorithms, and Libraries * Architecture, Networks/Communication, and Management * Programming and Systems Software * Data, Storage, and Visualization PROCEEDINGS: Proceedings of the conference and workshops will be available online when the conference starts and will be submitted to IEEE Xplore and for EI indexing. SPECIAL JOURNAL ISSUE: The best papers of Cluster 2015 will be included in a Special Issue on advances in topics related to cluster computing of the Elsevier International Journal of Parallel Computing (PARCO), edited by Pavan Balaji, Satoshi Matsuoka, and Michela Taufer. This special issue is dedicated for the papers accepted in the Cluster 2015 conference. The submission to this special issue is by invitation only. IMPORTANT DATES September 27, 2014 Submissions open for Workshops January 1, 2015 ... Submissions open for Papers, Posters, and Tutorials February 27, 2015 ... Papers Submission Deadline April 23, 2015 ... Papers Acceptance Notification May 1, 2015 . Posters Submission Deadline May 1, 2015 . Submissions open for Student Mentoring Program June 1, 2015 Student Mentoring Program Notification (Round 1) June 15, 2015 .. Posters Acceptance Notification June 15, 2015 .. Student Mentoring Program Notification (Round 2) June 29, 2015 .. Student Mentoring Program Notification (Round 3) July 13, 2015 ... Student Mentoring Program Notification (Round 4) July 13, 2015 ... Student Mentoring Program NSF Grant Notification August 1, 2015 Camera-ready Copy Deadline for Papers, Posters, and Workshops Workshop/Tutorial proposals are selected and notifications are sent on a first-come basis. SUBMISSION GUIDELINES Authors are invited to submit papers electronically in PDF format. Submitted manuscripts should be structured as technical papers and may not exceed 10 letter-size (8.5 x 11) pages including figures, tables and references using the IEEE format for conference proceedings. Submissions not conforming to these guidelines may be returned without review. Authors should make sure that their file will print on a printer that uses letter-size (8.5 x 11) paper. The official language of the conference is English. All manuscripts will be reviewed and will be judged on correctness, originality, technical strength, significance, quality of presentation, and interest and relevance to the conference attendees. Paper submissions are limited to 10 pages in 2-column IEEE format including all figures and references. Submitted manuscripts exceeding this limit will be returned without review. For the final camera-ready version, authors with accepted papers may purchase additional pages at the following rates: 200 USD for each of two additional pages. See formatting templates for details: * LaTex Package http://datasys.cs.iit.edu/events/CCGrid2014/IEEECS_confs_LaTeX.zip * Word Template http://datasys.cs.iit.edu/events/CCGrid2014/instruct8.5x11x2.doc Submitted papers must represent original unpublished research that is not currently under review for any other conference or journal. Papers not following these guidelines will be rejected without review and further action may be taken, including (but not limited to) notifications sent to the heads of the institutions of the authors and sponsors of the conference. Submissions received after the due date, exceeding the page limit, or not appropriately structured may not be considered. Authors may contact the conference chairs for more information. The proceedings will be published through the IEEE Computer Society Conference Publishing Services. ORGANIZATION:: -General Co-chairs: Pavan Balaji (Argonne National Laboratory, USA), Michela Taufer
