* Re: [RFC][PATCH] virtio balloon: kill tell-host-first logic
From: Dave Hansen @ 2011-04-14 20:28 UTC (permalink / raw)
To: Amit Shah
Cc: Anthony Liguori, virtualization, linux-kernel, Michael S. Tsirkin
In-Reply-To: <20110412164341.GQ13631@amit-x200.redhat.com>
On Tue, 2011-04-12 at 22:13 +0530, Amit Shah wrote:
> On (Tue) 12 Apr 2011 [09:22:32], Dave Hansen wrote:
> > On Tue, 2011-04-12 at 11:13 +0530, Amit Shah wrote:
> > > Sure, the only contention was on the commit message, where you stated
> > > modern qemus set this... qemu doesn't, and it should. Care to do a
> > > patch for that?
> >
> > If Rusty hasn't pushed the commit out anywhere, we can still amend the
> > commit. Otherwise, we're in a _bit_ of a pickle since you can't patch
> > git logs. :)
>
> I should've been clearer: care to do the qemu patch? :-)
What do we want to do to qemu, though? Set the bit?
-- Dave
^ permalink raw reply
* Re: [RFC][PATCH] virtio balloon: kill tell-host-first logic
From: Rusty Russell @ 2011-04-14 11:37 UTC (permalink / raw)
To: Dave Hansen, Amit Shah
Cc: Anthony Liguori, virtualization, linux-kernel, Michael S. Tsirkin
In-Reply-To: <1302625352.8321.2126.camel@nimitz>
On Tue, 12 Apr 2011 09:22:32 -0700, Dave Hansen <dave@linux.vnet.ibm.com> wrote:
> On Tue, 2011-04-12 at 11:13 +0530, Amit Shah wrote:
> > Sure, the only contention was on the commit message, where you stated
> > modern qemus set this... qemu doesn't, and it should. Care to do a
> > patch for that?
>
> If Rusty hasn't pushed the commit out anywhere, we can still amend the
> commit. Otherwise, we're in a _bit_ of a pickle since you can't patch
> git logs. :)
I only use git to send patches to Linus, and even if I did, I certainly
wouldn't try to publish an non-rebasing tree for exactly this reason.
So send me the new commit, or just the new message...
Thanks,
Rusty.
^ permalink raw reply
* Re: [Xen-devel] Re: [PATCH] xen: drop anti-dependency on X86_VISWS
From: Jeremy Fitzhardinge @ 2011-04-14 8:20 UTC (permalink / raw)
To: Ian Campbell
Cc: randy.dunlap@oracle.com, Jeremy Fitzhardinge,
eric.dumazet@gmail.com, konrad.wilk@oracle.com, David Miller,
Jan Beulich, virtualization@lists.linux-foundation.org,
mingo@redhat.com, hpa@zytor.com, tglx@linutronix.de,
mirq-linux@rere.qmqm.pl, pazke@donpac.ru,
xen-devel@lists.xensource.com
In-Reply-To: <1302345292.10419.15.camel@localhost.localdomain>
On 04/09/2011 03:34 AM, Ian Campbell wrote:
>>> Actually it does - see the "#ifndef CONFIG_X86_CMPXCHG" section
>>> in asm/cmpxchg_32.h.
>> Hm, OK. Still, I'm happiest with that dependency in case someone
>> knobbles the cpu to exclude cmpxchg and breaks things.
> Dropping the TSC patch is sensible though?
You mean dropping the TSC dependency? Yes, I think so.
J
^ permalink raw reply
* SNAPI2011 Call for Participation (7th IEEE International Workshop on Storage Network Architecture and Parallel I/O)
From: Ming Zhao @ 2011-04-13 14:34 UTC (permalink / raw)
To: virtualization
Updates:
* Early registration ends in a week!
* Program is available online: http://snapi2011.cis.fiu.edu/
========================================================================
Call for Participation
7th IEEE International Workshop on
Storage Network Architecture and Parallel I/Os
(SNAPI 2011)
http://snapi2011.cis.fiu.edu
May 25, 2011 Denver, Colorado, USA
In conjunction with the 27th IEEE Conference on
Mass Storage Systems and Technologies (MSST 2011)
========================================================================
SNAPI 2011, the 7th IEEE International Workshop on Storage Network
Architecture and Parallel I/O, will highlight the latest research in the
architecture, design, implementation, and evaluation of local and networked
storage and parallel I/O systems. This year, the program includes the
latest breakthroughs in solid-state storage technology, the latest
improvements in conventional storage technologies, and new horizons in
large-scale storage systems and parallel I/O. The workshop starts off with
a keynote by Dr. Gary Grider, Deputy Division Director (HPC) at Los Alamos
National Lab on storage issues in next generation of exascale computing
machines. With adequate material for practitioners and researchers,
industry folk and academics, SNAPI 2011 has something new for everyone
related to storage.
The SNAPI 2011 program is now available here:
http://snapi2011.cis.fiu.edu/General/Program
SNAPI will be held on May 25th in the beautiful, historic Brown Palace
hotel in Denver and is co-located with the 27th IEEE Symposium on Mass
Storage Systems and Technologies:
http://www.brownpalace.com
We have a limited number of rooms reserved at the Brown Palace and the
adjacent Comfort Inn. The conference rates vary between the two facilities,
so please reserve your room early to get your choice of room and rate.
You will find the preliminary programs, hotel information, photos of the
hotel and the area, and other information at:
http://storageconference.org
Early registration ends in approximately one week. Please register early to
avail the discount!
^ permalink raw reply
* Re: irq allocation for pci drivers
From: Greg KH @ 2011-04-13 3:40 UTC (permalink / raw)
To: KY Srinivasan
Cc: linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
virtualization@lists.osdl.org
In-Reply-To: <6E21E5352C11B742B20C142EB499E0481CB17E@TK5EX14MBXC126.redmond.corp.microsoft.com>
On Tue, Apr 12, 2011 at 11:57:22PM +0000, KY Srinivasan wrote:
> Greg,
>
>
>
> Has something changed in the PCI code in the Linux-next tree – 2.6.39-rc1-12
> with
>
> regards to irq allocation? Earlier (a few weeks ago), the vmbus driver would
> get the irq allocated as part
>
> of it being now a pci driver. Currently, however the system is setting pdev->
> irq to
>
> 0 and needless to say, request_irq() is failing.
{sigh} Please fix your email client...
Anyway, I have no idea, please use 'git bisect' to track down the
problem commit that causes this.
thanks,
greg k-h
^ permalink raw reply
* irq allocation for pci drivers
From: KY Srinivasan @ 2011-04-12 23:57 UTC (permalink / raw)
To: gregkh@suse.de
Cc: devel@linuxdriverproject.org, linux-kernel@vger.kernel.org,
virtualization@lists.osdl.org
[-- Attachment #1.1: Type: text/plain, Size: 354 bytes --]
Greg,
Has something changed in the PCI code in the Linux-next tree - 2.6.39-rc1-12 with
regards to irq allocation? Earlier (a few weeks ago), the vmbus driver would get the irq allocated as part
of it being now a pci driver. Currently, however the system is setting pdev->irq to
0 and needless to say, request_irq() is failing.
Thanks,
K. Y
[-- Attachment #1.2: Type: text/html, Size: 2292 bytes --]
[-- Attachment #2: Type: text/plain, Size: 184 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC][PATCH] virtio balloon: kill tell-host-first logic
From: Amit Shah @ 2011-04-12 16:43 UTC (permalink / raw)
To: Dave Hansen
Cc: Anthony Liguori, virtualization, linux-kernel, Michael S. Tsirkin
In-Reply-To: <1302625352.8321.2126.camel@nimitz>
On (Tue) 12 Apr 2011 [09:22:32], Dave Hansen wrote:
> On Tue, 2011-04-12 at 11:13 +0530, Amit Shah wrote:
> > Sure, the only contention was on the commit message, where you stated
> > modern qemus set this... qemu doesn't, and it should. Care to do a
> > patch for that?
>
> If Rusty hasn't pushed the commit out anywhere, we can still amend the
> commit. Otherwise, we're in a _bit_ of a pickle since you can't patch
> git logs. :)
I should've been clearer: care to do the qemu patch? :-)
> Whatever is easiest for Rusty works for me.
>
> How about this for a replacement log?
>
> --
>
> The virtio balloon driver has a VIRTIO_BALLOON_F_MUST_TELL_HOST
> feature bit. Whenever the bit is set, we must always tell the
> host before we free pages back to the allocator. Without this
> feature, we might free a page (and have another user touch it)
> while the hypervisor is unprepared for it.
>
> But, if the bit is _not_ set, we are under no obligation to
> reverse the order; we're under no obligation to do _anything_.
> That's the state of affairs in current qemu:
>
> #define VIRTIO_BALLOON_F_MUST_TELL_HOST 0
Actually this is just the bit number; it doesn't get set.
Amit
^ permalink raw reply
* Re: [RFC][PATCH] virtio balloon: kill tell-host-first logic
From: Dave Hansen @ 2011-04-12 16:22 UTC (permalink / raw)
To: Amit Shah
Cc: Anthony Liguori, virtualization, linux-kernel, Michael S. Tsirkin
In-Reply-To: <20110412054330.GH26678@amit-x200.redhat.com>
On Tue, 2011-04-12 at 11:13 +0530, Amit Shah wrote:
> Sure, the only contention was on the commit message, where you stated
> modern qemus set this... qemu doesn't, and it should. Care to do a
> patch for that?
If Rusty hasn't pushed the commit out anywhere, we can still amend the
commit. Otherwise, we're in a _bit_ of a pickle since you can't patch
git logs. :)
Whatever is easiest for Rusty works for me.
How about this for a replacement log?
--
The virtio balloon driver has a VIRTIO_BALLOON_F_MUST_TELL_HOST
feature bit. Whenever the bit is set, we must always tell the
host before we free pages back to the allocator. Without this
feature, we might free a page (and have another user touch it)
while the hypervisor is unprepared for it.
But, if the bit is _not_ set, we are under no obligation to
reverse the order; we're under no obligation to do _anything_.
That's the state of affairs in current qemu:
#define VIRTIO_BALLOON_F_MUST_TELL_HOST 0
This patch makes the "tell host first" logic the only case. This
should make everybody happy, and reduce the amount of untested or
untestable code in the kernel.
This _also_ means that we don't have to preserve a pfn list
after the pages are freed, which should let us get rid of some
temporary storage (vb->pfns) eventually.
Signed-off-by: Dave Hansen <dave@linux.vnet.ibm.com>
-- Dave
^ permalink raw reply
* Re: [RFC][PATCH] virtio: 64 bit features
From: Michael S. Tsirkin @ 2011-04-12 14:45 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Carsten Otte, lguest, linux-s390, Heiko Carstens, linux-kernel,
virtualization, Martin Schwidefsky, linux390
In-Reply-To: <4DA45C08.4070304@de.ibm.com>
On Tue, Apr 12, 2011 at 04:04:56PM +0200, Christian Borntraeger wrote:
> Am 11.04.2011 18:55, schrieb Michael S. Tsirkin:
>
> Looks mostly good, but
>
>
> > --- a/drivers/s390/kvm/kvm_virtio.c
> > +++ b/drivers/s390/kvm/kvm_virtio.c
> > @@ -82,13 +82,13 @@ static unsigned desc_size(const struct kvm_device_desc *desc)
> > static u32 kvm_get_features(struct virtio_device *vdev)
>
> This should be u64.
>
Ugh. Sure. Will fix, thanks!
> > {
> > unsigned int i;
> > - u32 features = 0;
> > + u64 features = 0;
> > struct kvm_device_desc *desc = to_kvmdev(vdev)->desc;
> > u8 *in_features = kvm_vq_features(desc);
> >
> > - for (i = 0; i < min(desc->feature_len * 8, 32); i++)
> > + for (i = 0; i < min(desc->feature_len * 8, 64); i++)
> > if (in_features[i / 8] & (1 << (i % 8)))
> > - features |= (1 << i);
> > + features |= (1ull << i);
> > return features;
> > }
^ permalink raw reply
* Re: [RFC][PATCH] virtio: 64 bit features
From: Christian Borntraeger @ 2011-04-12 14:04 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Carsten Otte, lguest, linux-s390, Heiko Carstens, linux-kernel,
virtualization, Martin Schwidefsky, linux390
In-Reply-To: <20110411165525.GA1395@redhat.com>
Am 11.04.2011 18:55, schrieb Michael S. Tsirkin:
Looks mostly good, but
> --- a/drivers/s390/kvm/kvm_virtio.c
> +++ b/drivers/s390/kvm/kvm_virtio.c
> @@ -82,13 +82,13 @@ static unsigned desc_size(const struct kvm_device_desc *desc)
> static u32 kvm_get_features(struct virtio_device *vdev)
This should be u64.
> {
> unsigned int i;
> - u32 features = 0;
> + u64 features = 0;
> struct kvm_device_desc *desc = to_kvmdev(vdev)->desc;
> u8 *in_features = kvm_vq_features(desc);
>
> - for (i = 0; i < min(desc->feature_len * 8, 32); i++)
> + for (i = 0; i < min(desc->feature_len * 8, 64); i++)
> if (in_features[i / 8] & (1 << (i % 8)))
> - features |= (1 << i);
> + features |= (1ull << i);
> return features;
> }
^ permalink raw reply
* Re: [PATCH] virtio: decrement dev_index when device is unregistered
From: Stefan Hajnoczi @ 2011-04-12 9:09 UTC (permalink / raw)
To: Takuma Umeya; +Cc: Stephen Hemminger, linux-kernel, virtualization
In-Reply-To: <1526578879.12280.1302513088278.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com>
On Mon, Apr 11, 2011 at 10:11 AM, Takuma Umeya <tumeya@redhat.com> wrote:
> ----- Original Message -----
>> On Tue, Apr 5, 2011 at 5:49 AM, Takuma Umeya <tumeya@redhat.com>
>> wrote:
>> > When virtio device is removed, dev_index does not get decremented.
>> > The next device hotplug event results in consuming the next pci to
>> > the one that is suppose to be available.
>> >
>> > Signed-off-by: Takuma Umeya <tumeya@redhat.com>
>> >
>> > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
>> > index efb35aa..67fe71d 100644
>> > --- a/drivers/virtio/virtio.c
>> > +++ b/drivers/virtio/virtio.c
>> > @@ -216,6 +216,7 @@ EXPORT_SYMBOL_GPL(register_virtio_device);
>> > void unregister_virtio_device(struct virtio_device *dev)
>> > {
>> > device_unregister(&dev->dev);
>> > + dev_index--;
>>
>> I don't think there is any guarantee that virtio devices are
>> added/removed in first-in-last-out order.
>>
>> That means I could add a virtio-net device (index 0) followed by a
>> virtio-blk device (index 1). Now I remove the virtio-net device
>> (index 0) which causes me to decrement dev_index and hand index 1 out
>> again to the next device. This leaves us with virtio-blk (index 1)
>> and the new device with index 1, which is not unique.
>>
>> Perhaps I missed a constraint which prevents this from occurring?
> I believe the address is assigned up to 1f so using u32 value
> to track use/free. This should make the code immune to the scenario.
> Would this be adequate?
This issue was also brought up by Jens Axboe on your other patch for
virtio block devices. He suggested using idr. I think that would be
a nicer solution than a u32 bitfield.
I'm not sure where you got 0x1f from but that seems like an artifical
limitation. Nothing should stop us from having more virtio devices.
Stefan
^ permalink raw reply
* Re: [RFC][PATCH] virtio balloon: kill tell-host-first logic
From: Amit Shah @ 2011-04-12 5:43 UTC (permalink / raw)
To: Dave Hansen
Cc: Anthony Liguori, virtualization, linux-kernel, Michael S. Tsirkin
In-Reply-To: <1302559871.7286.16749.camel@nimitz>
On (Mon) 11 Apr 2011 [15:11:11], Dave Hansen wrote:
> On Mon, 2011-04-11 at 14:01 +0300, Michael S. Tsirkin wrote:
> > On Thu, Apr 07, 2011 at 10:43:25AM -0700, Dave Hansen wrote:
> > > The virtio balloon driver has a VIRTIO_BALLOON_F_MUST_TELL_HOST
> > > feature bit. Whenever the bit is set, we must always tell the
> > > host before we free pages back to the allocator. Without this
> > > we might free a page (and have another user touch it) while the
> > > hypervisor is unprepared for it.
> > >
> > > But, if the bit is _not_ set, we are under no obligation to
> > > reverse the order. Furthermore, all modern qemus set this bit.
> >
> > Which qemus do this, specifically? Amit Shah just pointed out to me
> > that upstream qemu.git and qemu-kvm.git don't seem to do this.
>
> I had a conversation with Anthony about it, and I think I managed to
> confuse myself somewhere. Just to be clear, all that I see in the
> qemu-kvm git tree right now (df85c051d780bca0ee2462cfeb8ef6d9552a19b0)
> is this:
>
> hw/virtio-balloon.h:#define VIRTIO_BALLOON_F_MUST_TELL_HOST 0 /* Tell before reclaiming pages */
>
> > Which qemu did you test this with?
>
> Probably a week or two old qemu-kvm.
>
> My changelog could probably use some work, but the patch still stands.
> The only requirement we have is that when
> VIRTIO_BALLOON_F_MUST_TELL_HOST is set we *MUST* tell the host, first.
> But, when it's not set, we can do whatever we want.
>
> So, we might as well always have the ...F_MUST_TELL_HOST behavior all
> the time.
Sure, the only contention was on the commit message, where you stated
modern qemus set this... qemu doesn't, and it should. Care to do a
patch for that?
Thanks,
Amit
^ permalink raw reply
* Re: [RFC][PATCH] virtio: 64 bit features
From: Rusty Russell @ 2011-04-12 3:25 UTC (permalink / raw)
To: Michael S. Tsirkin, Carsten Otte, Christian Borntraeger, linux390,
Martin Schwidefsky <schwidefs>
In-Reply-To: <20110411165525.GA1395@redhat.com>
On Mon, 11 Apr 2011 19:55:25 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> Extend features to 64 bit so we can use more
> transport bits.
>
> Future patches add two new feature bits which would
> exhaust the supply of transport feature bits,
> so let's add bit 31 to tell the guest that
> there are now 64 worth of features.
>
> For PCI this also changes the config layout.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This was pretty much the way I imagined it would work. We need a patch
to the spec and a lot of cross testing...
Thanks!
Rusty.
^ permalink raw reply
* Re: [RFC][PATCH] virtio balloon: kill tell-host-first logic
From: Dave Hansen @ 2011-04-11 22:11 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Anthony Liguori, linux-kernel, virtualization
In-Reply-To: <20110411110131.GA23123@redhat.com>
On Mon, 2011-04-11 at 14:01 +0300, Michael S. Tsirkin wrote:
> On Thu, Apr 07, 2011 at 10:43:25AM -0700, Dave Hansen wrote:
> > The virtio balloon driver has a VIRTIO_BALLOON_F_MUST_TELL_HOST
> > feature bit. Whenever the bit is set, we must always tell the
> > host before we free pages back to the allocator. Without this
> > we might free a page (and have another user touch it) while the
> > hypervisor is unprepared for it.
> >
> > But, if the bit is _not_ set, we are under no obligation to
> > reverse the order. Furthermore, all modern qemus set this bit.
>
> Which qemus do this, specifically? Amit Shah just pointed out to me
> that upstream qemu.git and qemu-kvm.git don't seem to do this.
I had a conversation with Anthony about it, and I think I managed to
confuse myself somewhere. Just to be clear, all that I see in the
qemu-kvm git tree right now (df85c051d780bca0ee2462cfeb8ef6d9552a19b0)
is this:
hw/virtio-balloon.h:#define VIRTIO_BALLOON_F_MUST_TELL_HOST 0 /* Tell before reclaiming pages */
> Which qemu did you test this with?
Probably a week or two old qemu-kvm.
My changelog could probably use some work, but the patch still stands.
The only requirement we have is that when
VIRTIO_BALLOON_F_MUST_TELL_HOST is set we *MUST* tell the host, first.
But, when it's not set, we can do whatever we want.
So, we might as well always have the ...F_MUST_TELL_HOST behavior all
the time.
-- Dave
^ permalink raw reply
* RE: Hyper-V vmbus driver
From: KY Srinivasan @ 2011-04-11 19:51 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
virtualization@lists.osdl.org
In-Reply-To: <20110411190708.GA21355@suse.de>
> -----Original Message-----
> From: Greg KH [mailto:gregkh@suse.de]
> Sent: Monday, April 11, 2011 3:07 PM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org
> Subject: Re: Hyper-V vmbus driver
>
> On Mon, Apr 11, 2011 at 06:46:24PM +0000, KY Srinivasan wrote:
> > Greg,
> >
> >
> >
> > Recently, you applied a patch-set from me that cleaned a bunch of architectural
> > issues in the vmbus driver.
> >
> > With that patch-set, I think I have addressed all architectural issues that I
> > am aware of.
> >
> > I was wondering if you would have the time to let me know what else would
> have
> > to be addressed
> >
> > in the vmbus driver, before it could be considered ready for exiting staging.
> > As always your help is
> >
> > greatly appreciated.
>
> Hm, interesting word wrapping there, might I consider a "real" email
> client one of these days? :)
>
> Anyway, yes, I discussed this with Hank last week at the LF Collab
> summit. I'll look at the vmbus code later this week when I catch up on
> all of my other work (stable, usb, tty, staging, etc.) that has piled up
> during my 2 week absence, and get back to you with what I feel is still
> needed to be done, if anything.
Thanks Greg.
Regards,
K. Y
>
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: Hyper-V vmbus driver
From: Greg KH @ 2011-04-11 19:07 UTC (permalink / raw)
To: KY Srinivasan
Cc: linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
virtualization@lists.osdl.org
In-Reply-To: <6E21E5352C11B742B20C142EB499E0481C8D35@TK5EX14MBXC126.redmond.corp.microsoft.com>
On Mon, Apr 11, 2011 at 06:46:24PM +0000, KY Srinivasan wrote:
> Greg,
>
>
>
> Recently, you applied a patch-set from me that cleaned a bunch of architectural
> issues in the vmbus driver.
>
> With that patch-set, I think I have addressed all architectural issues that I
> am aware of.
>
> I was wondering if you would have the time to let me know what else would have
> to be addressed
>
> in the vmbus driver, before it could be considered ready for exiting staging.
> As always your help is
>
> greatly appreciated.
Hm, interesting word wrapping there, might I consider a "real" email
client one of these days? :)
Anyway, yes, I discussed this with Hank last week at the LF Collab
summit. I'll look at the vmbus code later this week when I catch up on
all of my other work (stable, usb, tty, staging, etc.) that has piled up
during my 2 week absence, and get back to you with what I feel is still
needed to be done, if anything.
thanks,
greg k-h
^ permalink raw reply
* Hyper-V vmbus driver
From: KY Srinivasan @ 2011-04-11 18:46 UTC (permalink / raw)
To: gregkh@suse.de
Cc: devel@linuxdriverproject.org, linux-kernel@vger.kernel.org,
virtualization@lists.osdl.org
[-- Attachment #1.1: Type: text/plain, Size: 455 bytes --]
Greg,
Recently, you applied a patch-set from me that cleaned a bunch of architectural issues in the vmbus driver.
With that patch-set, I think I have addressed all architectural issues that I am aware of.
I was wondering if you would have the time to let me know what else would have to be addressed
in the vmbus driver, before it could be considered ready for exiting staging. As always your help is
greatly appreciated.
Regards,
K. Y
[-- Attachment #1.2: Type: text/html, Size: 2496 bytes --]
[-- Attachment #2: Type: text/plain, Size: 184 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [RFC][PATCH] virtio: 64 bit features
From: Michael S. Tsirkin @ 2011-04-11 16:55 UTC (permalink / raw)
To: Rusty Russell, Carsten Otte, Christian Borntraeger, linux390,
Martin Schwidefsky <schwidefs>
Extend features to 64 bit so we can use more
transport bits.
Future patches add two new feature bits which would
exhaust the supply of transport feature bits,
so let's add bit 31 to tell the guest that
there are now 64 worth of features.
For PCI this also changes the config layout.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
drivers/lguest/lguest_device.c | 8 ++++----
drivers/s390/kvm/kvm_virtio.c | 6 +++---
drivers/virtio/virtio.c | 8 ++++----
drivers/virtio/virtio_pci.c | 33 +++++++++++++++++++++++++++------
include/linux/virtio.h | 2 +-
include/linux/virtio_config.h | 15 +++++++++------
include/linux/virtio_pci.h | 9 ++++++++-
7 files changed, 56 insertions(+), 25 deletions(-)
diff --git a/drivers/lguest/lguest_device.c b/drivers/lguest/lguest_device.c
index 69c84a1..d2d6953 100644
--- a/drivers/lguest/lguest_device.c
+++ b/drivers/lguest/lguest_device.c
@@ -93,17 +93,17 @@ static unsigned desc_size(const struct lguest_device_desc *desc)
}
/* This gets the device's feature bits. */
-static u32 lg_get_features(struct virtio_device *vdev)
+static u64 lg_get_features(struct virtio_device *vdev)
{
unsigned int i;
- u32 features = 0;
+ u64 features = 0;
struct lguest_device_desc *desc = to_lgdev(vdev)->desc;
u8 *in_features = lg_features(desc);
/* We do this the slow but generic way. */
- for (i = 0; i < min(desc->feature_len * 8, 32); i++)
+ for (i = 0; i < min(desc->feature_len * 8, 64); i++)
if (in_features[i / 8] & (1 << (i % 8)))
- features |= (1 << i);
+ features |= (1ull << i);
return features;
}
diff --git a/drivers/s390/kvm/kvm_virtio.c b/drivers/s390/kvm/kvm_virtio.c
index 414427d..8c976d0 100644
--- a/drivers/s390/kvm/kvm_virtio.c
+++ b/drivers/s390/kvm/kvm_virtio.c
@@ -82,13 +82,13 @@ static unsigned desc_size(const struct kvm_device_desc *desc)
static u32 kvm_get_features(struct virtio_device *vdev)
{
unsigned int i;
- u32 features = 0;
+ u64 features = 0;
struct kvm_device_desc *desc = to_kvmdev(vdev)->desc;
u8 *in_features = kvm_vq_features(desc);
- for (i = 0; i < min(desc->feature_len * 8, 32); i++)
+ for (i = 0; i < min(desc->feature_len * 8, 64); i++)
if (in_features[i / 8] & (1 << (i % 8)))
- features |= (1 << i);
+ features |= (1ull << i);
return features;
}
diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index efb35aa..52b24d7 100644
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -112,7 +112,7 @@ static int virtio_dev_probe(struct device *_d)
struct virtio_device *dev = container_of(_d,struct virtio_device,dev);
struct virtio_driver *drv = container_of(dev->dev.driver,
struct virtio_driver, driver);
- u32 device_features;
+ u64 device_features;
/* We have a driver! */
add_status(dev, VIRTIO_CONFIG_S_DRIVER);
@@ -124,14 +124,14 @@ static int virtio_dev_probe(struct device *_d)
memset(dev->features, 0, sizeof(dev->features));
for (i = 0; i < drv->feature_table_size; i++) {
unsigned int f = drv->feature_table[i];
- BUG_ON(f >= 32);
- if (device_features & (1 << f))
+ BUG_ON(f >= 64);
+ if (device_features & (1ull << f))
set_bit(f, dev->features);
}
/* Transport features always preserved to pass to finalize_features. */
for (i = VIRTIO_TRANSPORT_F_START; i < VIRTIO_TRANSPORT_F_END; i++)
- if (device_features & (1 << i))
+ if (device_features & (1ull << i))
set_bit(i, dev->features);
dev->config->finalize_features(dev);
diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c
index 4fb5b2b..2a2ee72 100644
--- a/drivers/virtio/virtio_pci.c
+++ b/drivers/virtio/virtio_pci.c
@@ -44,6 +44,8 @@ struct virtio_pci_device
spinlock_t lock;
struct list_head virtqueues;
+ /* 64 bit features */
+ int features_hi;
/* MSI-X support */
int msix_enabled;
int intx_enabled;
@@ -103,26 +105,45 @@ static struct virtio_pci_device *to_vp_device(struct virtio_device *vdev)
}
/* virtio config->get_features() implementation */
-static u32 vp_get_features(struct virtio_device *vdev)
+static u64 vp_get_features(struct virtio_device *vdev)
{
struct virtio_pci_device *vp_dev = to_vp_device(vdev);
+ u32 flo, fhi;
- /* When someone needs more than 32 feature bits, we'll need to
+ /* When someone needs more than 32 feature bits, we need to
* steal a bit to indicate that the rest are somewhere else. */
- return ioread32(vp_dev->ioaddr + VIRTIO_PCI_HOST_FEATURES);
+ flo = ioread32(vp_dev->ioaddr + VIRTIO_PCI_HOST_FEATURES);
+ if (flo & (0x1 << VIRTIO_F_FEATURES_HI)) {
+ vp_dev->features_hi = 1;
+ iowrite32(0x1 << VIRTIO_F_FEATURES_HI,
+ vp_dev->ioaddr + VIRTIO_PCI_GUEST_FEATURES_HI);
+ } else {
+ vp_dev->features_hi = 0;
+ }
+ fhi = ioread32(vp_dev->ioaddr + VIRTIO_PCI_HOST_FEATURES_HI);
+ return ((u64)fhi << 32) | flo;
}
/* virtio config->finalize_features() implementation */
static void vp_finalize_features(struct virtio_device *vdev)
{
struct virtio_pci_device *vp_dev = to_vp_device(vdev);
+ u32 flo, fhi;
/* Give virtio_ring a chance to accept features. */
vring_transport_features(vdev);
- /* We only support 32 feature bits. */
- BUILD_BUG_ON(ARRAY_SIZE(vdev->features) != 1);
- iowrite32(vdev->features[0], vp_dev->ioaddr+VIRTIO_PCI_GUEST_FEATURES);
+ /* We only support 64 feature bits. */
+ BUILD_BUG_ON(ARRAY_SIZE(vdev->features) != 64 / BITS_PER_LONG);
+ flo = vdev->features[0];
+ fhi = vdev->features[64 / BITS_PER_LONG - 1] >> (64 - BITS_PER_LONG);
+ iowrite32(flo, vp_dev->ioaddr + VIRTIO_PCI_GUEST_FEATURES);
+ if (flo & (0x1 << VIRTIO_F_FEATURES_HI)) {
+ vp_dev->features_hi = 1;
+ iowrite32(fhi, vp_dev->ioaddr + VIRTIO_PCI_GUEST_FEATURES_HI);
+ } else {
+ vp_dev->features_hi = 0;
+ }
}
/* virtio config->get() implementation */
diff --git a/include/linux/virtio.h b/include/linux/virtio.h
index aff5b4f..718336b 100644
--- a/include/linux/virtio.h
+++ b/include/linux/virtio.h
@@ -105,7 +105,7 @@ struct virtio_device {
struct virtio_config_ops *config;
struct list_head vqs;
/* Note that this is a Linux set_bit-style bitmap. */
- unsigned long features[1];
+ unsigned long features[64 / BITS_PER_LONG];
void *priv;
};
diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h
index 800617b..b1a1981 100644
--- a/include/linux/virtio_config.h
+++ b/include/linux/virtio_config.h
@@ -18,16 +18,19 @@
/* We've given up on this device. */
#define VIRTIO_CONFIG_S_FAILED 0x80
-/* Some virtio feature bits (currently bits 28 through 31) are reserved for the
+/* Some virtio feature bits (currently bits 28 through 39) are reserved for the
* transport being used (eg. virtio_ring), the rest are per-device feature
* bits. */
#define VIRTIO_TRANSPORT_F_START 28
-#define VIRTIO_TRANSPORT_F_END 32
+#define VIRTIO_TRANSPORT_F_END 40
/* Do we get callbacks when the ring is completely used, even if we've
* suppressed them? */
#define VIRTIO_F_NOTIFY_ON_EMPTY 24
+/* Enables feature bits 32 to 63 (only really required for virtio_pci). */
+#define VIRTIO_F_FEATURES_HI 31
+
#ifdef __KERNEL__
#include <linux/err.h>
#include <linux/virtio.h>
@@ -72,7 +75,7 @@
* @del_vqs: free virtqueues found by find_vqs().
* @get_features: get the array of feature bits for this device.
* vdev: the virtio_device
- * Returns the first 32 feature bits (all we currently need).
+ * Returns the first 64 feature bits (all we currently need).
* @finalize_features: confirm what device features we'll be using.
* vdev: the virtio_device
* This gives the final feature bits for the device: it can change
@@ -92,7 +95,7 @@ struct virtio_config_ops {
vq_callback_t *callbacks[],
const char *names[]);
void (*del_vqs)(struct virtio_device *);
- u32 (*get_features)(struct virtio_device *vdev);
+ u64 (*get_features)(struct virtio_device *vdev);
void (*finalize_features)(struct virtio_device *vdev);
};
@@ -110,9 +113,9 @@ static inline bool virtio_has_feature(const struct virtio_device *vdev,
{
/* Did you forget to fix assumptions on max features? */
if (__builtin_constant_p(fbit))
- BUILD_BUG_ON(fbit >= 32);
+ BUILD_BUG_ON(fbit >= 64);
else
- BUG_ON(fbit >= 32);
+ BUG_ON(fbit >= 64);
if (fbit < VIRTIO_TRANSPORT_F_START)
virtio_check_driver_offered_feature(vdev, fbit);
diff --git a/include/linux/virtio_pci.h b/include/linux/virtio_pci.h
index 9a3d7c4..035b10e 100644
--- a/include/linux/virtio_pci.h
+++ b/include/linux/virtio_pci.h
@@ -55,9 +55,16 @@
/* Vector value used to disable MSI for queue */
#define VIRTIO_MSI_NO_VECTOR 0xffff
+/* An extended 32-bit r/o bitmask of the features supported by the host */
+#define VIRTIO_PCI_HOST_FEATURES_HI 0
+
+/* An extended 32-bit r/w bitmask of features activated by the guest */
+#define VIRTIO_PCI_GUEST_FEATURES_HI 4
+
/* The remaining space is defined by each driver as the per-driver
* configuration space */
-#define VIRTIO_PCI_CONFIG(dev) ((dev)->msix_enabled ? 24 : 20)
+#define VIRTIO_PCI_CONFIG(dev) ((dev)->features_hi ? 32 : \
+ (dev)->msix_enabled ? 24 : 20)
/* Virtio ABI version, this must match exactly */
#define VIRTIO_PCI_ABI_VERSION 0
--
1.7.5.rc1.1.gc22ff
^ permalink raw reply related
* Re: [RFC][PATCH] virtio balloon: kill tell-host-first logic
From: Michael S. Tsirkin @ 2011-04-11 11:01 UTC (permalink / raw)
To: Dave Hansen; +Cc: linux-kernel, virtualization
In-Reply-To: <20110407174325.ED21C82B@kernel>
On Thu, Apr 07, 2011 at 10:43:25AM -0700, Dave Hansen wrote:
>
> The virtio balloon driver has a VIRTIO_BALLOON_F_MUST_TELL_HOST
> feature bit. Whenever the bit is set, we must always tell the
> host before we free pages back to the allocator. Without this
> we might free a page (and have another user touch it) while the
> hypervisor is unprepared for it.
>
> But, if the bit is _not_ set, we are under no obligation to
> reverse the order. Furthermore, all modern qemus set this bit.
Which qemus do this, specifically? Amit Shah just pointed out to me
that upstream qemu.git and qemu-kvm.git don't seem to do this.
Which qemu did you test this with?
> So, the "tell second" code is completely unused and untestable.
> Quoting Anthony: "untested code is broken code".
>
> This _also_ means that we don't have to preserve a pfn list
> after the pages are freed, which should let us get rid of some
> temporary storage (vb->pfns) eventually.
>
>
> Signed-off-by: Dave Hansen <dave@linux.vnet.ibm.com>
> ---
>
> linux-2.6.git-dave/drivers/virtio/virtio_balloon.c | 21 ++++++++-------------
> 1 file changed, 8 insertions(+), 13 deletions(-)
>
> diff -puN drivers/virtio/virtio_balloon.c~kill-tell-host-first-logic drivers/virtio/virtio_balloon.c
> --- linux-2.6.git/drivers/virtio/virtio_balloon.c~kill-tell-host-first-logic 2011-04-07 10:23:12.016343374 -0700
> +++ linux-2.6.git-dave/drivers/virtio/virtio_balloon.c 2011-04-07 10:23:12.024343370 -0700
> @@ -40,9 +40,6 @@ struct virtio_balloon
> /* Waiting for host to ack the pages we released. */
> struct completion acked;
>
> - /* Do we have to tell Host *before* we reuse pages? */
> - bool tell_host_first;
> -
> /* The pages we've told the Host we're not using. */
> unsigned int num_pages;
> struct list_head pages;
> @@ -151,13 +148,14 @@ static void leak_balloon(struct virtio_b
> vb->num_pages--;
> }
>
> - if (vb->tell_host_first) {
> - tell_host(vb, vb->deflate_vq);
> - release_pages_by_pfn(vb->pfns, vb->num_pfns);
> - } else {
> - release_pages_by_pfn(vb->pfns, vb->num_pfns);
> - tell_host(vb, vb->deflate_vq);
> - }
> +
> + /*
> + * Note that if
> + * virtio_has_feature(vdev, VIRTIO_BALLOON_F_MUST_TELL_HOST);
> + * is true, we *have* to do it in this order
> + */
> + tell_host(vb, vb->deflate_vq);
> + release_pages_by_pfn(vb->pfns, vb->num_pfns);
> }
>
> static inline void update_stat(struct virtio_balloon *vb, int idx,
> @@ -325,9 +323,6 @@ static int virtballoon_probe(struct virt
> goto out_del_vqs;
> }
>
> - vb->tell_host_first
> - = virtio_has_feature(vdev, VIRTIO_BALLOON_F_MUST_TELL_HOST);
> -
> return 0;
>
> out_del_vqs:
> _
^ permalink raw reply
* Re: [PATCH] virtio: decrement dev_index when device is unregistered
From: Takuma Umeya @ 2011-04-11 9:11 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: Stephen Hemminger, linux-kernel, virtualization
In-Reply-To: <BANLkTi=DGfKuapLhvt62UVG_h7fzsRRo3g@mail.gmail.com>
----- Original Message -----
> On Tue, Apr 5, 2011 at 5:49 AM, Takuma Umeya <tumeya@redhat.com>
> wrote:
> > When virtio device is removed, dev_index does not get decremented.
> > The next device hotplug event results in consuming the next pci to
> > the one that is suppose to be available.
> >
> > Signed-off-by: Takuma Umeya <tumeya@redhat.com>
> >
> > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
> > index efb35aa..67fe71d 100644
> > --- a/drivers/virtio/virtio.c
> > +++ b/drivers/virtio/virtio.c
> > @@ -216,6 +216,7 @@ EXPORT_SYMBOL_GPL(register_virtio_device);
> > void unregister_virtio_device(struct virtio_device *dev)
> > {
> > device_unregister(&dev->dev);
> > + dev_index--;
>
> I don't think there is any guarantee that virtio devices are
> added/removed in first-in-last-out order.
>
> That means I could add a virtio-net device (index 0) followed by a
> virtio-blk device (index 1). Now I remove the virtio-net device
> (index 0) which causes me to decrement dev_index and hand index 1 out
> again to the next device. This leaves us with virtio-blk (index 1)
> and the new device with index 1, which is not unique.
>
> Perhaps I missed a constraint which prevents this from occurring?
I believe the address is assigned up to 1f so using u32 value
to track use/free. This should make the code immune to the scenario.
Would this be adequate?
diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index efb35aa..0c73507 100644
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -3,7 +3,7 @@
#include <linux/virtio_config.h>
/* Unique numbering for virtio devices. */
-static unsigned int dev_index;
+static u32 dev_index;
static ssize_t device_show(struct device *_d,
struct device_attribute *attr, char *buf)
@@ -187,12 +187,23 @@ EXPORT_SYMBOL_GPL(unregister_virtio_driver);
int register_virtio_device(struct virtio_device *dev)
{
- int err;
+ int err, count;
+ u32 testbit;
+
+ count = 0;
dev->dev.bus = &virtio_bus;
/* Assign a unique device index and hence name. */
- dev->index = dev_index++;
+ while (count < 32){
+ testbit = 1UL << count;
+ if(!(dev_index & testbit)){
+ dev->index = count;
+ dev_index |= testbit;
+ break;
+ }
+ count++;
+ }
dev_set_name(&dev->dev, "virtio%u", dev->index);
/* We always start by resetting the device, in case a previous
@@ -215,7 +226,13 @@ EXPORT_SYMBOL_GPL(register_virtio_device);
void unregister_virtio_device(struct virtio_device *dev)
{
+ u32 removebit;
+
+ removebit = 1UL << (dev->index);
+
device_unregister(&dev->dev);
+
+ dev_index ^= removebit;
}
EXPORT_SYMBOL_GPL(unregister_virtio_device);
>
> Stefan
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
^ permalink raw reply related
* Re: [RFC][PATCH] virtio balloon: kill tell-host-first logic
From: Rusty Russell @ 2011-04-09 22:48 UTC (permalink / raw)
Cc: Dave Hansen, virtualization, linux-kernel, Michael S. Tsirkin
In-Reply-To: <20110407174325.ED21C82B@kernel>
On Thu, 07 Apr 2011 10:43:25 -0700, Dave Hansen <dave@linux.vnet.ibm.com> wrote:
>
> The virtio balloon driver has a VIRTIO_BALLOON_F_MUST_TELL_HOST
> feature bit. Whenever the bit is set, we must always tell the
> host before we free pages back to the allocator. Without this
> we might free a page (and have another user touch it) while the
> hypervisor is unprepared for it.
>
> But, if the bit is _not_ set, we are under no obligation to
> reverse the order. Furthermore, all modern qemus set this bit.
> So, the "tell second" code is completely unused and untestable.
> Quoting Anthony: "untested code is broken code".
>
> This _also_ means that we don't have to preserve a pfn list
> after the pages are freed, which should let us get rid of some
> temporary storage (vb->pfns) eventually.
>
> Signed-off-by: Dave Hansen <dave@linux.vnet.ibm.com>
Thanks, applied!
Rusty.
^ permalink raw reply
* Re: [Xen-devel] Re: [PATCH] xen: drop anti-dependency on X86_VISWS
From: Ian Campbell @ 2011-04-09 10:34 UTC (permalink / raw)
To: Jeremy Fitzhardinge
Cc: randy.dunlap@oracle.com, Jeremy Fitzhardinge,
eric.dumazet@gmail.com, konrad.wilk@oracle.com, David Miller,
Jan Beulich, virtualization@lists.linux-foundation.org,
mingo@redhat.com, hpa@zytor.com, tglx@linutronix.de,
mirq-linux@rere.qmqm.pl, pazke@donpac.ru,
xen-devel@lists.xensource.com
In-Reply-To: <4D9F52D4.6030700@goop.org>
On Fri, 2011-04-08 at 11:24 -0700, Jeremy Fitzhardinge wrote:
> On 04/08/2011 08:42 AM, Jan Beulich wrote:
> >>>> On 08.04.11 at 17:25, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> >> On 04/07/2011 11:38 PM, Ian Campbell wrote:
> >>> Is there any downside to this patch (is X86_CMPXCHG in the same sort of
> >>> boat?)
> >> Only if we don't use cmpxchg in shared memory with other domains or the
> >> hypervisor. (I don't think it will dynamically switch between real and
> >> emulated cmpxchg depending on availability.)
We do use cmpxchg in the grant table code at least (actually,
sync_cmpxchng in that case).
> > Actually it does - see the "#ifndef CONFIG_X86_CMPXCHG" section
> > in asm/cmpxchg_32.h.
>
> Hm, OK. Still, I'm happiest with that dependency in case someone
> knobbles the cpu to exclude cmpxchg and breaks things.
Dropping the TSC patch is sensible though?
Ian.
^ permalink raw reply
* Re: [PATCH] xen: drop anti-dependency on X86_VISWS
From: H. Peter Anvin @ 2011-04-08 20:15 UTC (permalink / raw)
To: Ian Campbell
Cc: randy.dunlap@oracle.com, xen-devel@lists.xensource.com,
eric.dumazet@gmail.com, konrad.wilk@oracle.com,
mirq-linux@rere.qmqm.pl, mingo@redhat.com, Jeremy Fitzhardinge,
tglx@linutronix.de, virtualization@lists.linux-foundation.org,
pazke@donpac.ru, David Miller
In-Reply-To: <1302245177.31620.47.camel@localhost.localdomain>
On 04/07/2011 11:46 PM, Ian Campbell wrote:
>
> Any reason not switch it over at this point then?
>
Not really.
-hpa
^ permalink raw reply
* Re: [Xen-devel] Re: [PATCH] xen: drop anti-dependency on X86_VISWS
From: Jeremy Fitzhardinge @ 2011-04-08 18:24 UTC (permalink / raw)
To: Jan Beulich
Cc: randy.dunlap@oracle.com, Jeremy Fitzhardinge,
eric.dumazet@gmail.com, konrad.wilk@oracle.com,
virtualization@lists.linux-foundation.org, Ian Campbell,
mingo@redhat.com, xen-devel@lists.xensource.com, hpa@zytor.com,
tglx@linutronix.de, mirq-linux@rere.qmqm.pl, pazke@donpac.ru,
David Miller
In-Reply-To: <4D9F48E8020000780003AA48@vpn.id2.novell.com>
On 04/08/2011 08:42 AM, Jan Beulich wrote:
>>>> On 08.04.11 at 17:25, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>> On 04/07/2011 11:38 PM, Ian Campbell wrote:
>>> Is there any downside to this patch (is X86_CMPXCHG in the same sort of
>>> boat?)
>> Only if we don't use cmpxchg in shared memory with other domains or the
>> hypervisor. (I don't think it will dynamically switch between real and
>> emulated cmpxchg depending on availability.)
> Actually it does - see the "#ifndef CONFIG_X86_CMPXCHG" section
> in asm/cmpxchg_32.h.
Hm, OK. Still, I'm happiest with that dependency in case someone
knobbles the cpu to exclude cmpxchg and breaks things.
J
^ permalink raw reply
* [Xen-devel] Re: [PATCH] xen: drop anti-dependency on X86_VISWS
From: Jan Beulich @ 2011-04-08 15:42 UTC (permalink / raw)
To: Ian Campbell, Jeremy Fitzhardinge
Cc: randy.dunlap@oracle.com, Jeremy Fitzhardinge,
eric.dumazet@gmail.com, konrad.wilk@oracle.com,
virtualization@lists.linux-foundation.org, mingo@redhat.com,
xen-devel@lists.xensource.com, hpa@zytor.com, tglx@linutronix.de,
mirq-linux@rere.qmqm.pl, pazke@donpac.ru, David Miller
In-Reply-To: <4D9F28FE.9000803@goop.org>
>>> On 08.04.11 at 17:25, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> On 04/07/2011 11:38 PM, Ian Campbell wrote:
>> Is there any downside to this patch (is X86_CMPXCHG in the same sort of
>> boat?)
>
> Only if we don't use cmpxchg in shared memory with other domains or the
> hypervisor. (I don't think it will dynamically switch between real and
> emulated cmpxchg depending on availability.)
Actually it does - see the "#ifndef CONFIG_X86_CMPXCHG" section
in asm/cmpxchg_32.h.
Jan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox