Re: [PATCH 0/7] AlacrityVM guest drivers Reply-To:
How hard would it be to implement virtio over vbus and perhaps the virtio-net backend? This would leave only one variable in the comparison, clear misconceptions and make evaluation easier by judging each of vbus, venet etc separately on its own merits. The way things are now, it is unclear exactly where those performance improvements are coming from (or how much each component contributes) because there are too many variables. Replacing virtio-net by venet would be a hard proposition if only because virtio-net has (closed source) windows drivers available. There has to be shown that venet by itself does something significantly better that virtio-net can't be modified to do comparably well. Having venet in addition to virtio-net is also difficult, given that having only one set of paravirtual drivers in the kernel was the whole point behind virtio. Just a user's 0.02, Pantelis -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NV-CUDA: a new way in virtualization is possible?
It would be possible to use this technology in the KVM/Qemu project to achieve better performance? It could be a significative step for the develop in virtualization technology? Nothing is impossible, but it is at least not obvious how to pull off such a trick. Qemu/KVM is not embarrassingly parallelizable, at least not in a straightforward way imho. Someone, in experimental way, has (re)wrote the md-raid kernel modules using the CUDA framework to accelerate some features... and it seems that works fine. Why not for KVM/Qemu or related projects, including kernel/user-space extension? RAID is easy, as is FFT, graphics operations, cryptography etc. People have been parallelizing these algorithms for several years before even nvidia existed and CUDA is just a new backend to apply more or less the same techniques. KVM/Qemu on the other hand are not 100% CPU bound and are also not trivial to massively parallelize, so you might find the task a bit hard. HTH, Pantelis -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Paravirtualisation or not?
On Tue, May 5, 2009 at 11:37 AM, Stefan Hajnoczi stefa...@gmail.com wrote: If a set of drivers essentially implementing the virtio framework (virtio_pci, virtio_ring, virtio queues) were available for windows, that would be *really* neat. I haven't tried them myself but I think this will give you virtio-net for Windows: http://sourceforge.net/project/showfiles.php?group_id=180599package_id=267943 More information: http://www.linux-kvm.com/content/tip-how-setup-windows-guest-paravirtual-network-drivers Hi Stefan :) Sure, closed-source virtio-net drivers exist (in fact there is a newer version than the one you linked. I think it is 12/2008 distributed as an iso). The point (and the advantage of Xen in this area) is that Xen provides the source too under GPL. Even if there was source available for the virtio framework only (and not net at all) it would still be useful to others wanting to write virtio drivers for windows. It is harder for a third party to do this job because you would have to make the decision to either use the Windows DDK and samples (which means you can't release under GPL and thus you can't reuse or even look at the current virtio implementations) or use GPL and the current linux virtio code as a base but in this case you can forget DDK and the samples (at least that is my understanding). Cheers, Pantelis -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Paravirtualisation or not?
- paravirtualized drivers widely available both for Linux and Windows (Xen's drivers on windows can be hard and/or expensive to get) Well, Xen has GPL PV drivers for windows (at least for networking) which KVM doesn't have. There is a promise but no date attached to it. If a set of drivers essentially implementing the virtio framework (virtio_pci, virtio_ring, virtio queues) were available for windows, that would be *really* neat. But that is somewhat off topic :) -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Assign the correct pci id range to virtio_pci
I 'd be happy with a simple comment explaining the 0x103f (e.g., /* Not yet using the full 0x1000 - 0x10ef to hedge our bets in case we broke the ABI.*/ as explained above) Thanks, I like your patch. Where did this idea of experimental range come from, BTW? In the qemu sources, there is a file pci-ids.txt that documents the PCI ID rules. I 'm attaching it for your convenience. I prefer your module cmdline approach, as it discourages deployment with such numbers. Great, I like this way better too, because it allows using the full experimental range (16 IDs) while also allowing for breaking the virtio_pci ABI. Thanks, Pantelis PCI IDs for qemu Red Hat, Inc. donates a part of its device ID range to qemu, to be used for virtual devices. The vendor ID is 1af4 (formerly Qumranet ID). The 1000 - 10ff device ID range is used for VirtIO devices. The 1100 device ID is used as PCI Subsystem ID for existing hardware devices emulated by qemu. All other device IDs are reserved. VirtIO Device IDs - 1af4:1000 network device 1af4:1001 block device 1af4:1002 balloon device 1af4:1003 console device 1af4:1004 Reserved. to Contact Gerd Hoffmann kra...@redhat.com to get a 1af4:10ef device ID assigned for your new virtio device. 1af4:10f0 Available for experimental usage without registration. Must get to official ID when the code leaves the test lab (i.e. when seeking 1af4:10ff upstream merge or shipping a distro/product) to avoid conflicts.
Re: FW: Notification from Qemu to Guest
And as a part of handle output for kick in the qemu side I am simply calling
virtio_notify
static void virtio_sample_handle_output(VirtIODevice *vdev, VirtQueue *vq)
{
printf(Function = %s, Line = %d\n,__FUNCTION__,__LINE__);
virtio_notify(vdev, vq);
}
Kick is working fine as I am landing in Qemu when making that call, However
virtio_notify is not resulting in my callback invocation registered as part
find_vq.
Do you see any missing parts here?
I was playing a bit today with my own virtio driver (I have locally
applied my PCI ID patch) and I bumped into your problem
for a few minutes. I think what you are missing is that your queue is
empty and since you probably haven't negotiated the
VIRTIO_F_NOTIFY_ON_EMPTY feature, you are falling victim of this code in qemu:
hw/virtio.c:669
void virtio_notify(VirtIODevice *vdev, VirtQueue *vq)
{
/* Always notify when queue is empty (when feature acknowledge) */
if ((vring_avail_flags(vq) VRING_AVAIL_F_NO_INTERRUPT)
(!(vdev-features (1 VIRTIO_F_NOTIFY_ON_EMPTY)) ||
(vq-inuse || vring_avail_idx(vq) != vq-last_avail_idx)))
return;
This is why you are not getting your interrupt
vdev-isr |= 0x01;
virtio_update_irq(vdev);
}
HTH,
Pantelis
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Assign the correct pci id range to virtio_pci
On Tue, Apr 28, 2009 at 6:19 PM, Gerd Hoffmann kra...@redhat.com wrote: Hi, Ok, since a day has passed with no further comments, I 'll dare to assume everyone is happy with this solution. So, here is an implementation. I 've tested locally with my driver that uses 0x10f5 and it seems to work. Patch looks fine to me. cheers, Gerd Cool, Avi, Rusty, what do you think ? Pantelis -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Assign the correct pci id range to virtio_pci
On Mon, Apr 27, 2009 at 2:56 PM, Avi Kivity a...@redhat.com wrote:
Pantelis Koukousoulas wrote:
Or maybe
modprobe virtio-pci claim=0x10f2 claim=0x10f7
How about claim=0x10f2,0x10f7 instead so that it can be implemented as
a standard module array parameter?
Even better.
Ok, since a day has passed with no further comments, I 'll dare to
assume everyone
is happy with this solution. So, here is an implementation. I 've
tested locally with
my driver that uses 0x10f5 and it seems to work.
I am both attaching and inlining the patch because I 'm sure gmail
will mess it up
but I have no access to any other mailer at this time.
Feel free to rewrite any part that is too ugly.
Pantelis
From: Pantelis Koukousoulas pkt...@gmail.com
Date: Mon, 27 Apr 2009 20:49:20 +0300
Subject: [PATCH] Fix virtio_pci handling of PCI IDs
Currently virtio_pci does not claim the PCI IDs in the
experimental range 0x10f0-0x10ff. This means that
developers wanting to to the right thing and use
one of these IDs find that their drivers don't load.
In the end, this encourages developers to just hijack
an ID from the low end of the managed range (0x1000-0x103f).
Also, the choice of only claiming part of the available
managed range (0x1000-0x10ef) might seem arbitrary or
a typo to someone reading the code, since there is
no comment to explain/justify it.
After discussion of the problem in kvm-devel, this patch
attempts to fix these problems.
For the managed range we just add a comment to explain that
the reason for only claiming part of the range was
future-proofing against potential ABI breakage.
For the experimental range we implement a module parameter
to allow developers to claim the IDs they want individually.
E.g., to develop 2 virtio devices with IDs 0x10f3 and 0x10f5
you just add:
options virtio_pci claim=0x10f3,0x10f5
to e.g., /etc/modprobe.d/virtio.conf and you are set. This
way should also be ABI breakage-proof while still allowing
private development of up to 16 devices by the same organization
simultaneously (i.e., the full experimental range).
Gerd Hoffmann suggested a module parameter and Avi Kivity
suggested the claim= syntax.
Signed-off-by: Pantelis Koukousoulas pkt...@gmail.com
---
drivers/virtio/virtio_pci.c | 33 ++---
1 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c
index 330aacb..9337a1d 100644
--- a/drivers/virtio/virtio_pci.c
+++ b/drivers/virtio/virtio_pci.c
@@ -30,6 +30,10 @@ MODULE_DESCRIPTION(virtio-pci);
MODULE_LICENSE(GPL);
MODULE_VERSION(1);
+static int claim[16];
+module_param_array(claim, int, NULL, 0444);
+MODULE_PARM_DESC(claim, Claimed PCI IDs in the 0x10f0-0x10ff range);
+
/* Our device structure */
struct virtio_pci_device
{
@@ -318,6 +322,30 @@ static void virtio_pci_release_dev(struct device *_d)
kfree(vp_dev);
}
+/*
+ * We only claim devices = 0x1000 and = 0x103f from the managed
+ * range: leave the rest. This allows for potential breaking of the
+ * ABI in the future. We also allow explicit selective claiming of
+ * IDs in the experimental range 0x10f0 - 0x10ff via a module param.
+ */
+static inline int is_valid_virtio_pci_id(short id)
+{
+ int i;
+
+ if (id 0x1000 || (id 0x103f id 0x10f0) || id 0x10ff)
+ return 0;
+
+ if (id 0x10f0) { /* 0x10f0 - 0x10ff case: experimental range id */
+ for (i = 0; i ARRAY_SIZE(claim); i++) {
+ if (id == claim[i])
+ return 1;
+ }
+ return 0;
+ }
+
+ return 1;
+}
+
/* the PCI probing function */
static int __devinit virtio_pci_probe(struct pci_dev *pci_dev,
const struct pci_device_id *id)
@@ -325,9 +353,8 @@ static int __devinit virtio_pci_probe(struct
pci_dev *pci_dev,
struct virtio_pci_device *vp_dev;
int err;
- /* We only own devices = 0x1000 and = 0x103f: leave the rest. */
- if (pci_dev-device 0x1000 || pci_dev-device 0x103f)
- return -ENODEV;
+ if (!is_valid_virtio_pci_id(pci_dev-device))
+ return -ENODEV;
if (pci_dev-revision != VIRTIO_PCI_ABI_VERSION) {
printk(KERN_ERR virtio_pci: expected ABI version %d, got %d\n,
--
1.5.6.3
From daa4ba5078dd05f9e58d3f9a2327e5d60f345150 Mon Sep 17 00:00:00 2001
From: Pantelis Koukousoulas pkt...@gmail.com
Date: Mon, 27 Apr 2009 20:49:20 +0300
Subject: [PATCH] Fix virtio_pci handling of PCI IDs
Currently virtio_pci does not claim the PCI IDs in the
experimental range 0x10f0-0x10ff. This means that
developers wanting to to the right thing and use
one of these IDs find that their drivers don't load.
In the end, this encourages developers to just hijack
an ID from the low end of the managed range (0x1000-0x103f).
Also, the choice of only claiming part of the available
managed range (0x1000-0x10ef) might seem arbitrary
Re: [PATCH] Assign the correct pci id range to virtio_pci
I'd suggest to exclude the experimental range by default (enable via module parameter) to make clear it isn't for regular use. Module parameter on what? The module parameter parsing code is afaict provided by the end-driver (e.g., virtio-net) which only speaks virtio and has no idea there is an actual PCI device in the backend. Isn't it easier to just make it clear that a PCI id within the 0x1000-10ef range is a prerequisite for inclusion in mainline linux / qemu and leave it at that? Btw, including just a subset of the experimental range like e.g., 0x10f0-0x10f3 would be fine with me, if there is a desire to be compatible with the allow for breaking the ABI rationale for the 0x1000-0x103f range. Thanks, Pantelis -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Assign the correct pci id range to virtio_pci
Or maybe modprobe virtio-pci claim=0x10f2 claim=0x10f7 How about claim=0x10f2,0x10f7 instead so that it can be implemented as a standard module array parameter? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Assign the correct pci id range to virtio_pci
Please copy the virtio maintainer (Rusty Russell ru...@rustcorp.com.au) on virtio guest patches. Well, for now the issue is whether my understanding of qemu/pci-ids.txt and the comment in virtio_pci.c that both say that the full 0x1000 - 0x10ff range of PCI device IDs is donated for virtio_pci devices is correct. If that is true, virtio_pci only claiming 0x1000 - 0x103f doesn't make much sense to me and looks more like a typo, because there is no explicit justification (perhaps in a comment) either. (3f does not even show up in pci-ids.txt). The ranges mentioned there are: 1000 - 10ef (one needs to contact Gerd to reserve an unallocated ID in that range) and 10f0 - 10ff (available for experimental devices, a random ID in that range can be used during private development without asking anyone as long as you are not shipping anything using it) the range ef - f0 (exclusive) is reserved. From the above, my understanding is that virtio_pci should definitely claim at least 00 - ef and most likely it should claim f0-ff too. The only reason not to claim some IDs is to allow someone to have virtio PCI devices that do *not* use the virtio_pci infrastructure but why would we want that? The reason I asked here (I guess qemu-devel would be just as relevant or more, but it has more traffic) is because Anthony is the author of virtio_pci.c (at least it looks like it) so hopefully he knows if that 3f was a typo or not and Gerd is responsible for the PCI ID namespace management so he knows if pci-ids.txt is correct or not. Once this issue is clarified I 'm happy to resend the same or an improved version of the patch as appropriate. Thanks, Pantelis -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Assign the correct pci id range to virtio_pci
On Mon, Apr 27, 2009 at 3:44 AM, Anthony Liguori anth...@codemonkey.ws wrote:
Rusty Russell wrote:
On Sun, 26 Apr 2009 10:19:16 pm Avi Kivity wrote:
0x1000-0x10ff is correct. I don't know where the 0x103f came from.
Rusty?
We decided to hedge our bets in case we broke the ABI.
AFAICT there's no reason to claim the full range until we need it. Wake
me
when device #32 is used :)
Would be good to at least include the experiment range in case people are
making third-party virtio modules and want to play around without replacing
virtio-{pci,*}.
I 'd be happy with a simple comment explaining the 0x103f (e.g.,
/* Not yet using the full 0x1000 - 0x10ef to hedge our bets in case we
broke the ABI.*/
as explained above)
plus including the experimental range as Anthony proposed.
The reason I came across this was I was playing with such a simple third party
module and after reading pci-ids.txt I decided to choose 0x10f5 for myself
only to find out that virtio_pci (and therefore my driver too) would
not load any more.
Thanks,
Pantelis
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Assign the correct pci id range to virtio_pci
According to the file pci-ids.txt in qemu sources, the range of PCI
device IDs assigned to virtio_pci is 0x1000 to 0x10ff, with a few
subranges that have different rules regarding who can get an ID
there and how.
Nevertheless, the full range should be assigned to the generic
virtio_pci driver, so that all corresponding devices, including
the experimental/unreleased ones just work.
---
drivers/virtio/virtio_pci.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c
index 330aacb..db3f3b5 100644
--- a/drivers/virtio/virtio_pci.c
+++ b/drivers/virtio/virtio_pci.c
@@ -325,8 +325,8 @@ static int __devinit virtio_pci_probe(struct pci_dev
*pci_dev,
struct virtio_pci_device *vp_dev;
int err;
- /* We only own devices = 0x1000 and = 0x103f: leave the rest. */
- if (pci_dev-device 0x1000 || pci_dev-device 0x103f)
+ /* We only own devices = 0x1000 and = 0x10ff: leave the rest. */
+ if (pci_dev-device 0x1000 || pci_dev-device 0x10ff)
return -ENODEV;
if (pci_dev-revision != VIRTIO_PCI_ABI_VERSION) {
--
1.5.6.3
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
