* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
@ 2009-07-26 11:52 ` Avi Kivity
2009-07-26 11:55 ` Alexander Graf
` (23 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: Avi Kivity @ 2009-07-26 11:52 UTC (permalink / raw)
To: kvm-ppc
On 07/24/2009 07:30 PM, Alexander Graf wrote:
> KVM for PowerPC only supports embedded cores at the moment.
>
> While it makes sense to virtualize on small machines, it's even more fun
> to do so on big boxes. So I figured we need KVM for PowerPC64 as well.
>
> This patchset implements KVM support for Book3s_64 hosts and guest support
> for Book3s_64 and G3/G4.
>
> To really make use of this, you will also need a modified version of qemu
> that can deal with KVM on desktop cores. I will send out patches for those
> later, but want to get feedback on the kernel side first.
>
> In the meanwhile, use the qemu version from
> http://www.powerkvm.org/powerkvm.git which already includes all required
> patches to run G3/G4 and G5 guests.
>
>
> To not spam on everyone on the list, I figured I'd send this as a git pull
> request this time. If I did anything wrong, please tell me :-).
>
I will need some acks from ppc people. Obviously for the non-kvm bits,
but also for the kvm bits as I am not qualified to review ppc code.
> - use MMU Notifiers
>
What's the plan here?
> - use u64* for dirty log
>
>
Is this a userspace interface issue? if so it will need to be addressed
before merging.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
2009-07-26 11:52 ` Avi Kivity
@ 2009-07-26 11:55 ` Alexander Graf
2009-07-26 12:10 ` Avi Kivity
` (22 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: Alexander Graf @ 2009-07-26 11:55 UTC (permalink / raw)
To: kvm-ppc
On 26.07.2009, at 13:52, Avi Kivity wrote:
> On 07/24/2009 07:30 PM, Alexander Graf wrote:
>> KVM for PowerPC only supports embedded cores at the moment.
>>
>> While it makes sense to virtualize on small machines, it's even
>> more fun
>> to do so on big boxes. So I figured we need KVM for PowerPC64 as
>> well.
>>
>> This patchset implements KVM support for Book3s_64 hosts and guest
>> support
>> for Book3s_64 and G3/G4.
>>
>> To really make use of this, you will also need a modified version
>> of qemu
>> that can deal with KVM on desktop cores. I will send out patches
>> for those
>> later, but want to get feedback on the kernel side first.
>>
>> In the meanwhile, use the qemu version from
>> http://www.powerkvm.org/powerkvm.git which already includes all
>> required
>> patches to run G3/G4 and G5 guests.
>>
>>
>> To not spam on everyone on the list, I figured I'd send this as a
>> git pull
>> request this time. If I did anything wrong, please tell me :-).
>>
>
> I will need some acks from ppc people. Obviously for the non-kvm
> bits, but also for the kvm bits as I am not qualified to review ppc
> code.
Right, FWIW Ben would actually even prefer to take the whole thing in
his tree.
>> - use MMU Notifiers
>>
>
> What's the plan here?
Implement MMU Notifiers as soon as I fully understand them? :-)
I'm aware of the basic concept, but the callbacks still seem somewhat
magical to me.
>> - use u64* for dirty log
>>
>>
>
> Is this a userspace interface issue? if so it will need to be
> addressed before merging.
Yes, on big endian having a 64-bit kernel and 32-bit userspace breaks
when dirty log is ulong*. Nobody saw this until now, because it's not
a big deal on little endian.
I sent a patch doing the qemu side of things already, but haven't went
through the kvm bits yet. Basically we can't use set_bit and test_bit
for the dirty log, because they require us to have the bitmap as ulong*.
Alex
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
2009-07-26 11:52 ` Avi Kivity
2009-07-26 11:55 ` Alexander Graf
@ 2009-07-26 12:10 ` Avi Kivity
2009-07-26 12:26 ` Alexander Graf
` (21 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: Avi Kivity @ 2009-07-26 12:10 UTC (permalink / raw)
To: kvm-ppc
On 07/26/2009 02:55 PM, Alexander Graf wrote:
>> I will need some acks from ppc people. Obviously for the non-kvm
>> bits, but also for the kvm bits as I am not qualified to review ppc
>> code.
>
>
> Right, FWIW Ben would actually even prefer to take the whole thing in
> his tree.
That's likely to cause conflicts if some kvm API changes and needs
modifications to this code. Perhaps the best option is for the non-kvm
changes to go through the ppc tree, and for me to duplicate (but not
push) them.
>
>>> - use MMU Notifiers
>>>
>>
>> What's the plan here?
>
> Implement MMU Notifiers as soon as I fully understand them? :-)
> I'm aware of the basic concept, but the callbacks still seem somewhat
> magical to me.
Ask and I'll do my best to answer.
>
>>> - use u64* for dirty log
>>>
>>>
>>
>> Is this a userspace interface issue? if so it will need to be
>> addressed before merging.
>
> Yes, on big endian having a 64-bit kernel and 32-bit userspace breaks
> when dirty log is ulong*. Nobody saw this until now, because it's not
> a big deal on little endian.
>
> I sent a patch doing the qemu side of things already, but haven't went
> through the kvm bits yet. Basically we can't use set_bit and test_bit
> for the dirty log, because they require us to have the bitmap as ulong*.
>
Yuck. What do we do? Implement set_bit_u64() and friends?
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
` (2 preceding siblings ...)
2009-07-26 12:10 ` Avi Kivity
@ 2009-07-26 12:26 ` Alexander Graf
2009-07-26 12:46 ` Avi Kivity
` (20 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: Alexander Graf @ 2009-07-26 12:26 UTC (permalink / raw)
To: kvm-ppc
On 26.07.2009, at 14:10, Avi Kivity wrote:
> On 07/26/2009 02:55 PM, Alexander Graf wrote:
>>> I will need some acks from ppc people. Obviously for the non-kvm
>>> bits, but also for the kvm bits as I am not qualified to review
>>> ppc code.
>>
>>
>> Right, FWIW Ben would actually even prefer to take the whole thing
>> in his tree.
>
> That's likely to cause conflicts if some kvm API changes and needs
> modifications to this code. Perhaps the best option is for the non-
> kvm changes to go through the ppc tree, and for me to duplicate (but
> not push) them.
I agree, but that's for you two to decide I guess :-). Let's just wait
for Ben to wake up.
>>>> - use MMU Notifiers
>>>>
>>>
>>> What's the plan here?
>>
>> Implement MMU Notifiers as soon as I fully understand them? :-)
>> I'm aware of the basic concept, but the callbacks still seem
>> somewhat magical to me.
>
> Ask and I'll do my best to answer.
Cool, next week :-). The current version works fine without. And I
need a weekend for a change :-D.
>>>> - use u64* for dirty log
>>>>
>>>>
>>>
>>> Is this a userspace interface issue? if so it will need to be
>>> addressed before merging.
>>
>> Yes, on big endian having a 64-bit kernel and 32-bit userspace
>> breaks when dirty log is ulong*. Nobody saw this until now, because
>> it's not a big deal on little endian.
>>
>> I sent a patch doing the qemu side of things already, but haven't
>> went through the kvm bits yet. Basically we can't use set_bit and
>> test_bit for the dirty log, because they require us to have the
>> bitmap as ulong*.
>>
>
> Yuck. What do we do? Implement set_bit_u64() and friends?
That's what I'd think we should do, yes.
For qemu I sent a patch that always uses "uint64_t" because that works
fine with the current code (32-bit on 64-bit uses the right bytes for
LE, 64-bit on 64-bit doesn't change). PPC is not implement yet for
anyone either and for now we only have dirty logging with 64 bit
kernels and 32-bit or 64-bit userspace, so that's fine too.
As soon as someone implement dirty logging on a 32-bit big endian
target, it will break though, so before that day comes we need to
change set_bit to set_bit_64.
Alex
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
` (3 preceding siblings ...)
2009-07-26 12:26 ` Alexander Graf
@ 2009-07-26 12:46 ` Avi Kivity
2009-07-26 12:46 ` Alexander Graf
` (19 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: Avi Kivity @ 2009-07-26 12:46 UTC (permalink / raw)
To: kvm-ppc
On 07/26/2009 03:26 PM, Alexander Graf wrote:
> Cool, next week :-). The current version works fine without. And I
> need a weekend for a change :-D.
Having returned from a 10-day weekend, I can only recommend this.
>>
>> Yuck. What do we do? Implement set_bit_u64() and friends?
>
>
> That's what I'd think we should do, yes.
>
> For qemu I sent a patch that always uses "uint64_t" because that works
> fine with the current code (32-bit on 64-bit uses the right bytes for
> LE, 64-bit on 64-bit doesn't change). PPC is not implement yet for
> anyone either and for now we only have dirty logging with 64 bit
> kernels and 32-bit or 64-bit userspace, so that's fine too.
>
> As soon as someone implement dirty logging on a 32-bit big endian
> target, it will break though, so before that day comes we need to
> change set_bit to set_bit_64.
Perhaps we can get away with disabling 32-on-64 for the configurations
that break to start with.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
` (4 preceding siblings ...)
2009-07-26 12:46 ` Avi Kivity
@ 2009-07-26 12:46 ` Alexander Graf
2009-07-26 12:54 ` Alexander Graf
` (18 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: Alexander Graf @ 2009-07-26 12:46 UTC (permalink / raw)
To: kvm-ppc
On 26.07.2009, at 14:46, Avi Kivity wrote:
> On 07/26/2009 03:26 PM, Alexander Graf wrote:
>> Cool, next week :-). The current version works fine without. And I
>> need a weekend for a change :-D.
>
> Having returned from a 10-day weekend, I can only recommend this.
Hope you had fun and didn't read too much mail :-).
>>> Yuck. What do we do? Implement set_bit_u64() and friends?
>>
>>
>> That's what I'd think we should do, yes.
>>
>> For qemu I sent a patch that always uses "uint64_t" because that
>> works fine with the current code (32-bit on 64-bit uses the right
>> bytes for LE, 64-bit on 64-bit doesn't change). PPC is not
>> implement yet for anyone either and for now we only have dirty
>> logging with 64 bit kernels and 32-bit or 64-bit userspace, so
>> that's fine too.
>>
>> As soon as someone implement dirty logging on a 32-bit big endian
>> target, it will break though, so before that day comes we need to
>> change set_bit to set_bit_64.
>
> Perhaps we can get away with disabling 32-on-64 for the
> configurations that break to start with.
32-on-64 only breaks for big endian which nobody except for this
target implements. Since my PPC enabling patches for qemu change the
type to uint64_t always, nobody is broken right now.
Alex
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
` (5 preceding siblings ...)
2009-07-26 12:46 ` Alexander Graf
@ 2009-07-26 12:54 ` Alexander Graf
2009-07-26 12:56 ` Avi Kivity
` (17 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: Alexander Graf @ 2009-07-26 12:54 UTC (permalink / raw)
To: kvm-ppc
On 26.07.2009, at 14:56, Avi Kivity wrote:
> On 07/26/2009 03:46 PM, Alexander Graf wrote:
>>
>> On 26.07.2009, at 14:46, Avi Kivity wrote:
>>
>>> On 07/26/2009 03:26 PM, Alexander Graf wrote:
>>>> Cool, next week :-). The current version works fine without. And
>>>> I need a weekend for a change :-D.
>>>
>>> Having returned from a 10-day weekend, I can only recommend this.
>>
>> Hope you had fun and didn't read too much mail :-).
>
> I didn't read _any_ email.
>
>>> Perhaps we can get away with disabling 32-on-64 for the
>>> configurations that break to start with.
>>
>> 32-on-64 only breaks for big endian which nobody except for this
>> target implements. Since my PPC enabling patches for qemu change
>> the type to uint64_t always, nobody is broken right now.
>>
>
> That assumes you implement set_bit_u64(), no?
No, little endian works as-is :-).
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
` (6 preceding siblings ...)
2009-07-26 12:54 ` Alexander Graf
@ 2009-07-26 12:56 ` Avi Kivity
2009-07-26 17:25 ` Alexander Graf
` (16 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: Avi Kivity @ 2009-07-26 12:56 UTC (permalink / raw)
To: kvm-ppc
On 07/26/2009 03:46 PM, Alexander Graf wrote:
>
> On 26.07.2009, at 14:46, Avi Kivity wrote:
>
>> On 07/26/2009 03:26 PM, Alexander Graf wrote:
>>> Cool, next week :-). The current version works fine without. And I
>>> need a weekend for a change :-D.
>>
>> Having returned from a 10-day weekend, I can only recommend this.
>
> Hope you had fun and didn't read too much mail :-).
I didn't read _any_ email.
>> Perhaps we can get away with disabling 32-on-64 for the
>> configurations that break to start with.
>
> 32-on-64 only breaks for big endian which nobody except for this
> target implements. Since my PPC enabling patches for qemu change the
> type to uint64_t always, nobody is broken right now.
>
That assumes you implement set_bit_u64(), no?
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
` (7 preceding siblings ...)
2009-07-26 12:56 ` Avi Kivity
@ 2009-07-26 17:25 ` Alexander Graf
2009-07-26 17:53 ` Avi Kivity
` (15 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: Alexander Graf @ 2009-07-26 17:25 UTC (permalink / raw)
To: kvm-ppc
Am 26.07.2009 um 14:54 schrieb Alexander Graf <agraf@suse.de>:
>
> On 26.07.2009, at 14:56, Avi Kivity wrote:
>
>> On 07/26/2009 03:46 PM, Alexander Graf wrote:
>>>
>>> On 26.07.2009, at 14:46, Avi Kivity wrote:
>>>
>>>> On 07/26/2009 03:26 PM, Alexander Graf wrote:
>>>>> Cool, next week :-). The current version works fine without. And
>>>>> I need a weekend for a change :-D.
>>>>
>>>> Having returned from a 10-day weekend, I can only recommend this.
>>>
>>> Hope you had fun and didn't read too much mail :-).
>>
>> I didn't read _any_ email.
>>
>>>> Perhaps we can get away with disabling 32-on-64 for the
>>>> configurations that break to start with.
>>>
>>> 32-on-64 only breaks for big endian which nobody except for this
>>> target implements. Since my PPC enabling patches for qemu change
>>> the type to uint64_t always, nobody is broken right now.
>>>
>>
>> That assumes you implement set_bit_u64(), no?
>
> No, little endian works as-is :-).
Let me rephrase: It shouldn't if I understand little endian
correctly :).
I haven't actually verified that 32 on 64 doesn't break. But then
again that's a rather uncommon configuration for x86 anyways, but
really common on ppc.
Alex
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
` (8 preceding siblings ...)
2009-07-26 17:25 ` Alexander Graf
@ 2009-07-26 17:53 ` Avi Kivity
2009-07-26 20:47 ` Alexander Graf
` (14 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: Avi Kivity @ 2009-07-26 17:53 UTC (permalink / raw)
To: kvm-ppc
On 07/26/2009 08:25 PM, Alexander Graf wrote:
>>>
>>>>> Perhaps we can get away with disabling 32-on-64 for the
>>>>> configurations that break to start with.
>>>>
>>>> 32-on-64 only breaks for big endian which nobody except for this
>>>> target implements. Since my PPC enabling patches for qemu change
>>>> the type to uint64_t always, nobody is broken right now.
>>>>
>>>
>>> That assumes you implement set_bit_u64(), no?
>>
>> No, little endian works as-is :-).
>
>
> Let me rephrase: It shouldn't if I understand little endian correctly :).
>
> I haven't actually verified that 32 on 64 doesn't break. But then
> again that's a rather uncommon configuration for x86 anyways, but
> really common on ppc.
I meant disable 32-on-64 ppc. 32-on-64 x86 is supported and works
(though it is rare).
Given that you say 32-on-64 ppc is common, it could only be a short term
fix until we implemlement u64 bitops. Alternatively we can mangle the
bitmap when copying it to userspace.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
` (9 preceding siblings ...)
2009-07-26 17:53 ` Avi Kivity
@ 2009-07-26 20:47 ` Alexander Graf
2009-07-26 22:04 ` Benjamin Herrenschmidt
` (13 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: Alexander Graf @ 2009-07-26 20:47 UTC (permalink / raw)
To: kvm-ppc
Am 26.07.2009 um 19:53 schrieb Avi Kivity <avi@redhat.com>:
> On 07/26/2009 08:25 PM, Alexander Graf wrote:
>>>>
>>>>>> Perhaps we can get away with disabling 32-on-64 for the
>>>>>> configurations that break to start with.
>>>>>
>>>>> 32-on-64 only breaks for big endian which nobody except for this
>>>>> target implements. Since my PPC enabling patches for qemu change
>>>>> the type to uint64_t always, nobody is broken right now.
>>>>>
>>>>
>>>> That assumes you implement set_bit_u64(), no?
>>>
>>> No, little endian works as-is :-).
>>
>>
>> Let me rephrase: It shouldn't if I understand little endian
>> correctly :).
>>
>> I haven't actually verified that 32 on 64 doesn't break. But then
>> again that's a rather uncommon configuration for x86 anyways, but
>> really common on ppc.
>
> I meant disable 32-on-64 ppc. 32-on-64 x86 is supported and works
> (though it is rare).
>
> Given that you say 32-on-64 ppc is common, it could only be a short
> term fix until we implemlement u64 bitops. Alternatively we can
> mangle the bitmap when copying it to userspace.
When we just interpret the bitmap as u64* do we break 32 on 64 x86? If
not, that makes it work for 32 on 64 ppc, because the kernel is always
64.
Alex
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
` (10 preceding siblings ...)
2009-07-26 20:47 ` Alexander Graf
@ 2009-07-26 22:04 ` Benjamin Herrenschmidt
2009-07-26 22:05 ` Benjamin Herrenschmidt
` (12 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: Benjamin Herrenschmidt @ 2009-07-26 22:04 UTC (permalink / raw)
To: kvm-ppc
On Sun, 2009-07-26 at 15:10 +0300, Avi Kivity wrote:
> Yuck. What do we do? Implement set_bit_u64() and friends?
We may be able to hijack some of the filesystem ones... those are used
for on-disk format so should fit the bill
Cheers,
Ben.
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
` (11 preceding siblings ...)
2009-07-26 22:04 ` Benjamin Herrenschmidt
@ 2009-07-26 22:05 ` Benjamin Herrenschmidt
2009-07-26 22:06 ` Benjamin Herrenschmidt
` (11 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: Benjamin Herrenschmidt @ 2009-07-26 22:05 UTC (permalink / raw)
To: kvm-ppc
On Sun, 2009-07-26 at 14:26 +0200, Alexander Graf wrote:
> On 26.07.2009, at 14:10, Avi Kivity wrote:
>
> > On 07/26/2009 02:55 PM, Alexander Graf wrote:
> >>> I will need some acks from ppc people. Obviously for the non-kvm
> >>> bits, but also for the kvm bits as I am not qualified to review
> >>> ppc code.
> >>
> >>
> >> Right, FWIW Ben would actually even prefer to take the whole thing
> >> in his tree.
> >
> > That's likely to cause conflicts if some kvm API changes and needs
> > modifications to this code. Perhaps the best option is for the non-
> > kvm changes to go through the ppc tree, and for me to duplicate (but
> > not push) them.
>
> I agree, but that's for you two to decide I guess :-). Let's just wait
> for Ben to wake up.
I need to review and test a bit, hopefully I'll have a better idea of
what goes where some time this week.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
` (12 preceding siblings ...)
2009-07-26 22:05 ` Benjamin Herrenschmidt
@ 2009-07-26 22:06 ` Benjamin Herrenschmidt
2009-07-26 22:11 ` Benjamin Herrenschmidt
` (10 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: Benjamin Herrenschmidt @ 2009-07-26 22:06 UTC (permalink / raw)
To: kvm-ppc
On Sun, 2009-07-26 at 15:46 +0300, Avi Kivity wrote:
> >
> > As soon as someone implement dirty logging on a 32-bit big endian
> > target, it will break though, so before that day comes we need to
> > change set_bit to set_bit_64.
>
> Perhaps we can get away with disabling 32-on-64 for the
> configurations
> that break to start with.
Well, 32-on-64 is probably still the most widely used configuration on
ppc
Cheers,
Ben.
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
` (13 preceding siblings ...)
2009-07-26 22:06 ` Benjamin Herrenschmidt
@ 2009-07-26 22:11 ` Benjamin Herrenschmidt
2009-07-27 19:04 ` Hollis Blanchard
` (9 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: Benjamin Herrenschmidt @ 2009-07-26 22:11 UTC (permalink / raw)
To: kvm-ppc
On Sun, 2009-07-26 at 22:47 +0200, Alexander Graf wrote:
> When we just interpret the bitmap as u64* do we break 32 on 64 x86? If
> not, that makes it work for 32 on 64 ppc, because the kernel is always
> 64.
It just a matter of having the bits in the right place. The kernel will
not always be 64-bit though, for example it's no for kvm/e500 or kvm/440
and there's no reason those could get gfx at some stage.
Now, the kernel -does- provide _le variants of the bitops, and those
have the side advantage of being agnostic to 32 vs. 64 bit so maybe that
what we should use everywhere ?
Look at ppc's bitops.h, it has nice descriptions of the format.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
` (14 preceding siblings ...)
2009-07-26 22:11 ` Benjamin Herrenschmidt
@ 2009-07-27 19:04 ` Hollis Blanchard
2009-07-27 23:43 ` Benjamin Herrenschmidt
` (8 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: Hollis Blanchard @ 2009-07-27 19:04 UTC (permalink / raw)
To: kvm-ppc
On Sun, 2009-07-26 at 15:10 +0300, Avi Kivity wrote:
> On 07/26/2009 02:55 PM, Alexander Graf wrote:
> >> I will need some acks from ppc people. Obviously for the non-kvm
> >> bits, but also for the kvm bits as I am not qualified to review
> ppc
> >> code.
> >
> >
> > Right, FWIW Ben would actually even prefer to take the whole thing
> in
> > his tree.
>
> That's likely to cause conflicts if some kvm API changes and needs
> modifications to this code. Perhaps the best option is for the
> non-kvm
> changes to go through the ppc tree, and for me to duplicate (but not
> push) them.
The way I've done this in the past is to get acks from PPC maintainers,
and then push the patches through Avi.
If a "generic" PPC patch is required by a KVM patch, pushing them
through different trees would leave KVM broken for weeks until it all
ends up merged in Linus's tree.
Despite Ben's newfound interest in KVM, I don't see a good reason to
change this model. :)
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
` (15 preceding siblings ...)
2009-07-27 19:04 ` Hollis Blanchard
@ 2009-07-27 23:43 ` Benjamin Herrenschmidt
2009-07-29 10:14 ` Avi Kivity
` (7 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: Benjamin Herrenschmidt @ 2009-07-27 23:43 UTC (permalink / raw)
To: kvm-ppc
On Mon, 2009-07-27 at 12:04 -0700, Hollis Blanchard wrote:
>
> The way I've done this in the past is to get acks from PPC
> maintainers,
> and then push the patches through Avi.
>
> If a "generic" PPC patch is required by a KVM patch, pushing them
> through different trees would leave KVM broken for weeks until it all
> ends up merged in Linus's tree.
>
> Despite Ben's newfound interest in KVM, I don't see a good reason to
> change this model. :)
Depends how invasive the powerpc bits are. I'll figure something out.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
` (16 preceding siblings ...)
2009-07-27 23:43 ` Benjamin Herrenschmidt
@ 2009-07-29 10:14 ` Avi Kivity
2009-07-29 10:15 ` Avi Kivity
` (6 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: Avi Kivity @ 2009-07-29 10:14 UTC (permalink / raw)
To: kvm-ppc
On 07/28/2009 02:43 AM, Benjamin Herrenschmidt wrote:
> On Mon, 2009-07-27 at 12:04 -0700, Hollis Blanchard wrote:
>
>> The way I've done this in the past is to get acks from PPC
>> maintainers,
>> and then push the patches through Avi.
>>
>> If a "generic" PPC patch is required by a KVM patch, pushing them
>> through different trees would leave KVM broken for weeks until it all
>> ends up merged in Linus's tree.
>>
>> Despite Ben's newfound interest in KVM, I don't see a good reason to
>> change this model. :)
>>
>
> Depends how invasive the powerpc bits are. I'll figure something out.
>
Yes. If they are invasive, the best way is to carry the non-kvm changes
in both trees, and for me to push after you (I'll omit the duplicates
when pushing).
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
` (17 preceding siblings ...)
2009-07-29 10:14 ` Avi Kivity
@ 2009-07-29 10:15 ` Avi Kivity
2009-09-02 5:40 ` Benjamin Herrenschmidt
` (5 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: Avi Kivity @ 2009-07-29 10:15 UTC (permalink / raw)
To: kvm-ppc
On 07/26/2009 11:47 PM, Alexander Graf wrote:
> When we just interpret the bitmap as u64* do we break 32 on 64 x86? If
> not, that makes it work for 32 on 64 ppc, because the kernel is always
> 64.
No. little-endian is insensitive to the word size for bitops.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
` (18 preceding siblings ...)
2009-07-29 10:15 ` Avi Kivity
@ 2009-09-02 5:40 ` Benjamin Herrenschmidt
2009-09-02 6:16 ` Alexander Graf
` (4 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: Benjamin Herrenschmidt @ 2009-09-02 5:40 UTC (permalink / raw)
To: kvm-ppc
On Fri, 2009-07-24 at 18:30 +0200, Alexander Graf wrote:
> KVM for PowerPC only supports embedded cores at the moment.
>
> While it makes sense to virtualize on small machines, it's even more fun
> to do so on big boxes. So I figured we need KVM for PowerPC64 as well.
>
> This patchset implements KVM support for Book3s_64 hosts and guest support
> for Book3s_64 and G3/G4.
>
> To really make use of this, you will also need a modified version of qemu
> that can deal with KVM on desktop cores. I will send out patches for those
> later, but want to get feedback on the kernel side first.
>
> In the meanwhile, use the qemu version from
> http://www.powerkvm.org/powerkvm.git which already includes all required
> patches to run G3/G4 and G5 guests.
The git pull request is good when the series is good to pull or for
testing, but for review patches are nice :-)
So I never got enough time to look into too much details so far
(I'm still up for a little walkthrough on IRC one of these days
btw) but I did look at the changes to the powerpc core code and
they look ok to me.
The only thing I couldn't quite figure out is why you are adding
exports for mm_alloc() and switch_slb().
I spotted tons of stuff that could be optimized, especially in the
interrupt handling (but then, we all agree that using a magic page
is going to be much better), and I suppose we need to have a close
look at some aspects of the MMU emulation.
But for now, I'm happy with the merge, feel free to add my Acked-by,
just make sure it's marked CONFIG_EXPERIMENTAL.
Avi, are you taking care of it from here ?
Cheers,
Ben.
>
> To not spam on everyone on the list, I figured I'd send this as a git pull
> request this time. If I did anything wrong, please tell me :-).
>
> V1 -> V2:
>
> - extend sregs with padding
> - new naming scheme (ppc64 -> book3s_64; 74xx -> book3s_32)
> - to_phys -> in-kernel tophys()
> - loadimm -> LOAD_REG_IMMEDIATE
> - call .ko kvm.ko
> - set magic paca bit later
> - run guest code with PACA->soft_enabled=true
> - pt_regs for host state saving (guest too?)
> - only do HV dcbz trick on 970
> - refuse to run on LPAR because of missing SLB pieces
>
> V2 -> V3:
>
> - fix DAR/DSISR saving
> - allow running on LPAR by modifying the SLB shadow
> - change the SLB implementation to use a mem-backed cache and do
> full world switch on enter/exit. gets rid of "context" magic
> - be more aggressive about DEC injection
> - remove fast ld/st because we're always in host context
> - don't use SPRGs in real->paged transition
> - implement dirty log
> - remove MMIO speedup code
> - SPRG cleanup
> - rename SPRG3 -> SPRN_SPRG_PACA
> - rename SPRG1 -> SPRN_SPRG_SCRATCH0
> - don't use SPRG2
>
> TODO:
>
> - use MMU Notifiers
> - use u64* for dirty log
>
>
>
>
> The following changes since commit 84a3c0818fe9d7a1e34c188d6182793f213a6a66:
> Gleb Natapov (1):
> KVM: Reduce runnability interface with arch support code
>
> are available in the git repository at:
>
> git://csgraf.de/kvm ppc-v3
>
> Alexander Graf (25):
> Move dirty logging code to sub-arch
> Pass PVR in sregs
> Add Book3s definitions
> Add Book3s fields to vcpu structs
> Add asm/kvm_book3s.h
> Add Book3s_64 intercept helpers
> Add book3s_64 highmem asm code
> Add SLB switching code for entry/exit
> Add interrupt handling code
> Add book3s.c
> Add book3s_64 Host MMU handling
> Add book3s_64 guest MMU
> Add book3s_32 guest MMU
> Add book3s_64 specific opcode emulation
> Add mfdec emulation
> Add desktop PowerPC specific emulation
> Make head_64.S aware of KVM real mode code
> Add Book3s_64 offsets to asm-offsets.c
> Export symbols for KVM module
> Export KVM symbols for module
> Add fields to PACA
> Export new PACA constants in asm-offsets
> Include Book3s_64 target in buildsystem
> Fix trace.h
> Enable 32bit dirty log pointers on 64bit host
>
> arch/powerpc/include/asm/exception.h | 2 +
> arch/powerpc/include/asm/kvm.h | 2 +
> arch/powerpc/include/asm/kvm_asm.h | 49 ++
> arch/powerpc/include/asm/kvm_book3s.h | 135 ++++
> arch/powerpc/include/asm/kvm_book3s_64_asm.h | 58 ++
> arch/powerpc/include/asm/kvm_host.h | 76 +++-
> arch/powerpc/include/asm/kvm_ppc.h | 1 +
> arch/powerpc/include/asm/paca.h | 9 +
> arch/powerpc/kernel/asm-offsets.c | 18 +
> arch/powerpc/kernel/exceptions-64s.S | 8 +
> arch/powerpc/kernel/head_64.S | 6 +
> arch/powerpc/kernel/ppc_ksyms.c | 3 +-
> arch/powerpc/kernel/time.c | 1 +
> arch/powerpc/kvm/Kconfig | 17 +
> arch/powerpc/kvm/Makefile | 27 +-
> arch/powerpc/kvm/book3s.c | 919 ++++++++++++++++++++++++++
> arch/powerpc/kvm/book3s_32_mmu.c | 354 ++++++++++
> arch/powerpc/kvm/book3s_64_emulate.c | 338 ++++++++++
> arch/powerpc/kvm/book3s_64_exports.c | 24 +
> arch/powerpc/kvm/book3s_64_interrupts.S | 392 +++++++++++
> arch/powerpc/kvm/book3s_64_mmu.c | 469 +++++++++++++
> arch/powerpc/kvm/book3s_64_mmu_host.c | 412 ++++++++++++
> arch/powerpc/kvm/book3s_64_rmhandlers.S | 131 ++++
> arch/powerpc/kvm/book3s_64_slb.S | 277 ++++++++
> arch/powerpc/kvm/booke.c | 5 +
> arch/powerpc/kvm/emulate.c | 43 ++-
> arch/powerpc/kvm/powerpc.c | 5 -
> arch/powerpc/kvm/trace.h | 6 +-
> arch/powerpc/mm/hash_utils_64.c | 2 +
> arch/powerpc/mm/mmu_context_hash64.c | 4 +
> arch/powerpc/mm/slb.c | 2 +
> kernel/fork.c | 1 +
> virt/kvm/kvm_main.c | 5 +
> 33 files changed, 3786 insertions(+), 15 deletions(-)
> create mode 100644 arch/powerpc/include/asm/kvm_book3s.h
> create mode 100644 arch/powerpc/include/asm/kvm_book3s_64_asm.h
> create mode 100644 arch/powerpc/kvm/book3s.c
> create mode 100644 arch/powerpc/kvm/book3s_32_mmu.c
> create mode 100644 arch/powerpc/kvm/book3s_64_emulate.c
> create mode 100644 arch/powerpc/kvm/book3s_64_exports.c
> create mode 100644 arch/powerpc/kvm/book3s_64_interrupts.S
> create mode 100644 arch/powerpc/kvm/book3s_64_mmu.c
> create mode 100644 arch/powerpc/kvm/book3s_64_mmu_host.c
> create mode 100644 arch/powerpc/kvm/book3s_64_rmhandlers.S
> create mode 100644 arch/powerpc/kvm/book3s_64_slb.S
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
` (19 preceding siblings ...)
2009-09-02 5:40 ` Benjamin Herrenschmidt
@ 2009-09-02 6:16 ` Alexander Graf
2009-09-02 6:23 ` Benjamin Herrenschmidt
` (3 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: Alexander Graf @ 2009-09-02 6:16 UTC (permalink / raw)
To: kvm-ppc
On 02.09.2009, at 07:40, Benjamin Herrenschmidt wrote:
> On Fri, 2009-07-24 at 18:30 +0200, Alexander Graf wrote:
>> KVM for PowerPC only supports embedded cores at the moment.
>>
>> While it makes sense to virtualize on small machines, it's even
>> more fun
>> to do so on big boxes. So I figured we need KVM for PowerPC64 as
>> well.
>>
>> This patchset implements KVM support for Book3s_64 hosts and guest
>> support
>> for Book3s_64 and G3/G4.
>>
>> To really make use of this, you will also need a modified version
>> of qemu
>> that can deal with KVM on desktop cores. I will send out patches
>> for those
>> later, but want to get feedback on the kernel side first.
>>
>> In the meanwhile, use the qemu version from
>> http://www.powerkvm.org/powerkvm.git which already includes all
>> required
>> patches to run G3/G4 and G5 guests.
>
> The git pull request is good when the series is good to pull or for
> testing, but for review patches are nice :-)
Ok, guess I'll go back to sending patches in the future then ;-).
> So I never got enough time to look into too much details so far
> (I'm still up for a little walkthrough on IRC one of these days
> btw) but I did look at the changes to the powerpc core code and
> they look ok to me.
>
> The only thing I couldn't quite figure out is why you are adding
> exports for mm_alloc() and switch_slb().
Well, we need mm_alloc to reserve a VA range. And since that happens
in module code, it needs to be exported.
As far as switch_slb goes, I think with the new "always switch the
full SLB in entry/exit code" logic, that's not required anymore.
> I spotted tons of stuff that could be optimized
Yes. It might also be worth collecting all the potential optimizations
on some wiki, so if someone feels like jumping in on this project, he
knows where to start. It'd even be good for us, because I always tend
to forget where exactly the code is the worst :-).
> , especially in the
> interrupt handling (but then, we all agree that using a magic page
> is going to be much better)
The interrupt handling is a separate beast that should be handled more
generically, but the current code works for KVM at least. Let's take
baby steps here.
> , and I suppose we need to have a close
> look at some aspects of the MMU emulation.
I fully agree. The MMU emulation could probably also get quite some
speedups. For the first version I merely wanted to have something that
boots and runs Linux.
> But for now, I'm happy with the merge, feel free to add my Acked-by,
> just make sure it's marked CONFIG_EXPERIMENTAL.
It definitely is experimental still, so yes, I agree.
Should I send out a v4 that removes the slb_switch export and marks
things as experimental?
Alex
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
` (20 preceding siblings ...)
2009-09-02 6:16 ` Alexander Graf
@ 2009-09-02 6:23 ` Benjamin Herrenschmidt
2009-09-02 6:34 ` Alexander Graf
` (2 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: Benjamin Herrenschmidt @ 2009-09-02 6:23 UTC (permalink / raw)
To: kvm-ppc
> Well, we need mm_alloc to reserve a VA range. And since that happens
> in module code, it needs to be exported.
Hrm... I've missed where you call it. Can't you directly allocate
a context ID instead of a whole mm ?
> As far as switch_slb goes, I think with the new "always switch the
> full SLB in entry/exit code" logic, that's not required anymore.
Ok. In general, I'd rather keep the KVM SLB switching separate from
the "normal" one since there's different constraints anyways.
> Should I send out a v4 that removes the slb_switch export and marks
> things as experimental?
Please, and add my Acks. Pls dbl check the need for mm_alloc() though.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
` (21 preceding siblings ...)
2009-09-02 6:23 ` Benjamin Herrenschmidt
@ 2009-09-02 6:34 ` Alexander Graf
2009-09-02 6:52 ` Benjamin Herrenschmidt
2009-09-02 15:21 ` Hollis Blanchard
24 siblings, 0 replies; 26+ messages in thread
From: Alexander Graf @ 2009-09-02 6:34 UTC (permalink / raw)
To: kvm-ppc
On 02.09.2009, at 08:23, Benjamin Herrenschmidt wrote:
>> Well, we need mm_alloc to reserve a VA range. And since that happens
>> in module code, it needs to be exported.
>
> Hrm... I've missed where you call it. Can't you directly allocate
> a context ID instead of a whole mm ?
It's in the vcpu init code:
./book3s.c:862: vcpu->arch.mm_guest = mm_alloc();
And the mm_alloc() call was the closest I could find to only allocate
a context ID. I didn't really want to change too much code in there
unless I really have to and it seems like mm_alloc doesn't have that
much overhead.
>> As far as switch_slb goes, I think with the new "always switch the
>> full SLB in entry/exit code" logic, that's not required anymore.
>
> Ok. In general, I'd rather keep the KVM SLB switching separate from
> the "normal" one since there's different constraints anyways.
Yes, that's why we're at v3 already :-).
>> Should I send out a v4 that removes the slb_switch export and marks
>> things as experimental?
>
> Please, and add my Acks. Pls dbl check the need for mm_alloc() though.
I'm open for suggestions on how to get a context_id easily/cleanly
without exporting mm_alloc.
Alex
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
` (22 preceding siblings ...)
2009-09-02 6:34 ` Alexander Graf
@ 2009-09-02 6:52 ` Benjamin Herrenschmidt
2009-09-02 15:21 ` Hollis Blanchard
24 siblings, 0 replies; 26+ messages in thread
From: Benjamin Herrenschmidt @ 2009-09-02 6:52 UTC (permalink / raw)
To: kvm-ppc
On Wed, 2009-09-02 at 08:34 +0200, Alexander Graf wrote:
> On 02.09.2009, at 08:23, Benjamin Herrenschmidt wrote:
>
> >> Well, we need mm_alloc to reserve a VA range. And since that happens
> >> in module code, it needs to be exported.
> >
> > Hrm... I've missed where you call it. Can't you directly allocate
> > a context ID instead of a whole mm ?
>
> It's in the vcpu init code:
>
> ./book3s.c:862: vcpu->arch.mm_guest = mm_alloc();
>
> And the mm_alloc() call was the closest I could find to only allocate
> a context ID. I didn't really want to change too much code in there
> unless I really have to and it seems like mm_alloc doesn't have that
> much overhead.
>
> I'm open for suggestions on how to get a context_id easily/cleanly
> without exporting mm_alloc.
I see ... init_new_context() and destroy_context() only operate on an
mm_struct... Well, in that case, I'm open to something that would change
those two to __init_new_context() and __destroy_conext() that
respectively return the new ID and take an ID as an argument, which you
can export, and have static inlines in mmu-context.h that implement
init_new_context() and destroy_context() in terms of the above.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3
2009-07-24 16:30 [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3 Alexander Graf
` (23 preceding siblings ...)
2009-09-02 6:52 ` Benjamin Herrenschmidt
@ 2009-09-02 15:21 ` Hollis Blanchard
24 siblings, 0 replies; 26+ messages in thread
From: Hollis Blanchard @ 2009-09-02 15:21 UTC (permalink / raw)
To: kvm-ppc
On Wed, 2009-09-02 at 15:40 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2009-07-24 at 18:30 +0200, Alexander Graf wrote:
> > KVM for PowerPC only supports embedded cores at the moment.
> >
> > While it makes sense to virtualize on small machines, it's even more fun
> > to do so on big boxes. So I figured we need KVM for PowerPC64 as well.
> >
> > This patchset implements KVM support for Book3s_64 hosts and guest support
> > for Book3s_64 and G3/G4.
> >
> > To really make use of this, you will also need a modified version of qemu
> > that can deal with KVM on desktop cores. I will send out patches for those
> > later, but want to get feedback on the kernel side first.
> >
> > In the meanwhile, use the qemu version from
> > http://www.powerkvm.org/powerkvm.git which already includes all required
> > patches to run G3/G4 and G5 guests.
>
> The git pull request is good when the series is good to pull or for
> testing, but for review patches are nice :-)
Yeah, I actually went looking for the v3 patchset last week, and gave up
trying to extract it from git...
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply [flat|nested] 26+ messages in thread