Fedora xen - May 2008 - Is pci-pasthrough enabled for F9 DomU?

i''ve F8 as Dom0.

for F8 DomU, pci-passthru devices are visible via lspci *in* DomU.

for a new install of F9 DomU, lcpci is (empty).

there was discussion that PCI-PassThrough might not make it into F9,

 http://lists.xensource.com/archives/html/xen-devel/2007-12/msg00454.html
  "> F9 may well end up lacking features compared to Xen in Fedora 8
&
earlier (eg no
   > PCI device passthrough, or CPU hotplug)"

but release notes,

 
http://fedoraproject.org/wiki/Features/XenPvops#head-e15c9305e8d715da9d904a1a99e658409cf12929

make no mention one way or other.

*is* pci-passthru known/supposed to work in F9 DomU?

if so, then i''ve got a different issue ...

On Tue, May 13, 2008 at 04:08:38PM -0700, snowcrash+xen@gmail.com
wrote:
> i''ve F8 as Dom0.
> 
> for F8 DomU, pci-passthru devices are visible via lspci *in* DomU.
> 
> for a new install of F9 DomU, lcpci is (empty).
> 
> there was discussion that PCI-PassThrough might not make it into F9,
> 
>  http://lists.xensource.com/archives/html/xen-devel/2007-12/msg00454.html
>   "> F9 may well end up lacking features compared to Xen in Fedora
8 &
> earlier (eg no
>    > PCI device passthrough, or CPU hotplug)"
> 
> but release notes,
> 
>  
http://fedoraproject.org/wiki/Features/XenPvops#head-e15c9305e8d715da9d904a1a99e658409cf12929
> 
> make no mention one way or other.
> 
> *is* pci-passthru known/supposed to work in F9 DomU?
No.  Only  block, network and framebuffer devices were implemented in 
the F9 DomU kernel.

Regards,
Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

>  > *is* pci-passthru known/supposed to work in F9 DomU?
>
>  No.  Only  block, network and framebuffer devices were implemented in
>  the F9 DomU kernel.
argh. not what i was hoping to hear :-/ but, good to know (should it
be added to the ''release notes'', above?), i''ve been
spinning my wheels
here.

any rough sense for a ''when'' it''ll be back?
soon-to-F10, i''d guess,
but *any* add''l guidance would be helpful ...

without it, back to F8 for a couple of DomUs.

thanks!

On Tue, May 13, 2008 at 04:31:30PM -0700, snowcrash+xen@gmail.com
wrote:
> >  > *is* pci-passthru known/supposed to work in F9 DomU?
> >
> >  No.  Only  block, network and framebuffer devices were implemented in
> >  the F9 DomU kernel.
> 
> argh. not what i was hoping to hear :-/ but, good to know (should it
> be added to the ''release notes'', above?), i''ve
been spinning my wheels
> here.
> 
> any rough sense for a ''when'' it''ll be back?
soon-to-F10, i''d guess,
> but *any* add''l guidance would be helpful ...
This isn''t what you''ll want to hear but...

To be perfectly honest, it is not really a high priority. Our priorities
are getting the DomU stuff merged upstream & working reliably and continuing
the Dom0 work, since those impact every single user of Xen. Unfortunately 
PCI pasthrough is quite a niche userbase, so its hard to justify work on it
in the short term given limited resources. If someone has skills & time to 
volunteer to work on the PCI passthrough stuff.....

Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

>  This isn''t what you''ll want to hear but...
>
>  To be perfectly honest, it is not really a high priority. Our priorities
>  are getting the DomU stuff merged upstream & working reliably and
continuing
>  the Dom0 work, since those impact every single user of Xen. Unfortunately
>  PCI pasthrough is quite a niche userbase, so its hard to justify work on
it
>  in the short term given limited resources. If someone has skills &
time to
>  volunteer to work on the PCI passthrough stuff.....
ouch!  a large %age of the boxes we deploy have a firewall/DomU & and
a NAS/Domu, each with dedicated, pass''d-thru NICs.  without passthru,
performance is lousy.

so, iiuc "not really a high priority", i guess -- short of
''growing''
someone with the skills -- we''re hosed.

the unfortunate irony is we *moved* to Fedora because the passthru
support in RHEL was flaky, and Fedora was touted as "the right way to
get it".  regressing a working feature that differentiates the distro
would not have been my first choice ... majority, or otherwise.

thanks for the straight-up !

now to figure out *which* supported distro CAN fit my needs. sigh.

On Tue, May 13, 2008 at 04:55:04PM -0700, snowcrash+xen@gmail.com
wrote:
> >  This isn''t what you''ll want to hear but...
> >
> >  To be perfectly honest, it is not really a high priority. Our
priorities
> >  are getting the DomU stuff merged upstream & working reliably and
continuing
> >  the Dom0 work, since those impact every single user of Xen.
Unfortunately
> >  PCI pasthrough is quite a niche userbase, so its hard to justify work
on it
> >  in the short term given limited resources. If someone has skills
& time to
> >  volunteer to work on the PCI passthrough stuff.....
> 
> ouch!  a large %age of the boxes we deploy have a firewall/DomU & and
> a NAS/Domu, each with dedicated, pass''d-thru NICs.  without
passthru,
> performance is lousy.
> 
> so, iiuc "not really a high priority", i guess -- short of
''growing''
> someone with the skills -- we''re hosed.
> 
> the unfortunate irony is we *moved* to Fedora because the passthru
> support in RHEL was flaky, and Fedora was touted as "the right way to
> get it".  regressing a working feature that differentiates the distro
> would not have been my first choice ... majority, or otherwise.
PCI passthrough *is* supported in RHEL-5 Xen kernels. There was a bug in the
RHEL-5.1 Dom0 userspace, but that is fixed in 5.2. AFAIK, any RHEL-5.x 
guest supports PCI passthrough.

Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

On Tue, May 13, 2008 at 04:55:04PM -0700, snowcrash+xen@gmail.com
wrote:
> ouch!  a large %age of the boxes we deploy have a firewall/DomU & and
> a NAS/Domu, each with dedicated, pass''d-thru NICs.  without
passthru,
> performance is lousy.
You''re aware that PCI passthrough is insecure?  Someone who gets root
access to a guest can reprogram the NICs (trivially) to read or write
any area of memory in any guest or the dom0.  This might be pertinent
information if you were expecting your firewall to provide isolation.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is ''top'' for virtual machines.  Tiny program with
many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

hi,
>  You''re aware that PCI passthrough is insecure?  Someone who gets
root
>  access to a guest can reprogram the NICs (trivially) to read or write
>  any area of memory in any guest or the dom0.  This might be pertinent
>  information if you were expecting your firewall to provide isolation.
nope. 1st i''m hearing of it ... not that i haven''t looked :-/
sigh.

hrm.

so, although this is "just" a RH/Fedora forum, but xen focussed, let
me then ask ...

i *want* a distro with

-- X86_64/SMP (AMD multicore) support
-- Xen 3.2.x builds & runs both in Dom0 & DomU
-- capable of deploying a FW in DomU that does not suffer
NIC-performance degradation -- or (apparently) security holes
-- stable core that''ll keep us ''supported'' (e.g.,
*not* the Fedaora
scenario i''m now facing; feature-incomplete until, perhaps, F10+, @
which point F8 -- which we''re "stuck" on is unsupported)
-- app repos (rpm, srpm, other ...) that are safe/available/reliable
for full releases (one example, Bind 9.4.2, which seems to be tough to
find for RHEL/Centos 5.1)

*can* i (yet) "have it all"?  iiuc, "no" ....

On Wed, May 14, 2008 at 08:23:32AM -0700, snowcrash+xen@gmail.com
wrote:
> NIC-performance degradation -- or (apparently) security holes
Well, the security thing is a hardware limitation.  You''ll have to
wait for next-gen hardware to support VT-d (I think all of
motherboard, processor and PCI cards, though I may be wrong about
this).  There is some experimental support for VT-d in the latest Xen,
but not in RHEL 5.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is ''top'' for virtual machines.  Tiny program with
many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

On Wed, May 14, 2008 at 9:54 AM, Richard W.M. Jones <rjones@redhat.com>
wrote:
> On Tue, May 13, 2008 at 04:55:04PM -0700, snowcrash+xen@gmail.com wrote:
>  > ouch!  a large %age of the boxes we deploy have a firewall/DomU &
and
>  > a NAS/Domu, each with dedicated, pass''d-thru NICs.  without
passthru,
>  > performance is lousy.
>
>  You''re aware that PCI passthrough is insecure?  Someone who gets
root
>  access to a guest can reprogram the NICs (trivially) to read or write
>  any area of memory in any guest or the dom0.  This might be pertinent
>  information if you were expecting your firewall to provide isolation.
I figured that a domU having direct hardware access would open
security holes; however, the VM I built is for monitoring our Internet
connection, and I couldn''t figure a way to sniff that traffic without
direct hardware access.  It''s a tightly secured VM with only pinhole
access to it in any case.  If there''s a better way to configure a VM
for traffic sniffing, I''d be interested in hearing...

Regards,
David
-- 
David L. Parsley
Manager of Network Services, Bridgewater College
"If I have seen further, it is by standing on ye shoulders of giants"
- Isaac Newton

> If there''s a better way to configure a VM
> for traffic sniffing, I''d be interested in hearing...
as would i. :-/

my understanding (?) is that passthru to PV domu need to be eliminated
to avoid the aforementioned security hole.

that leaves passthru to HVM -- which requires AMD-V (or intel VT-d
...) extension support. and, i _think_ that means xen ver >= 3.2.0 is
required.

fedora9''s not an option. fedora8''s "not going to support
it" policy,
though understandable on the march to paravirt_ops, leaves little to
lean on in terms of community support ...

best option i''m finding so far is Centos51, with a rpmrebuild of xen
320 from src rpm,

 
http://bits.xensource.com/oss-xen/release/3.2.0/centos-5.1/xen-3.2.0-0xs.centos5.src.rpm

(if there''s a 3.2.1 src rpm available, i haven''t found it yet
...)

in the process of trying it myself ...

On Wed, May 14, 2008 at 11:48:33AM -0700, snowcrash+xen@gmail.com
wrote:
> > If there''s a better way to configure a VM
> > for traffic sniffing, I''d be interested in hearing...
> 
> as would i. :-/
> 
> my understanding (?) is that passthru to PV domu need to be eliminated
> to avoid the aforementioned security hole.
> 
> that leaves passthru to HVM -- which requires AMD-V (or intel VT-d
> ...) extension support. and, i _think_ that means xen ver >= 3.2.0 is
> required.
> 
> fedora9''s not an option. fedora8''s "not going to
support it" policy,
> though understandable on the march to paravirt_ops, leaves little to
> lean on in terms of community support ...
Sadly that''s life with Xen.  Upstream Xen has basically stopped all
kernel
development leaving ''official'' Xen kernels stuck on 2.6.28
which is
essentially useless for any modern distro. We had the choice between trying
to finish off the paravirt_ops port, or dropping Xen entirely :-(

Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

> Sadly that''s life with Xen.  Upstream Xen has basically stopped
all kernel
> development leaving ''official'' Xen kernels stuck on
2.6.28 which is
> essentially useless for any modern distro. We had the choice between trying
> to finish off the paravirt_ops port, or dropping Xen entirely :-(
not criticising the choice (well, much anyway ;-) ) ...

rather, just hunting for options that work -- if even for the short(ish) term

p.s. 2.6.28 a typo? that''s 2.6.18, no?

On Wed, May 14, 2008 at 11:58:21AM -0700, snowcrash+xen@gmail.com
wrote:
> > Sadly that''s life with Xen.  Upstream Xen has basically
stopped all kernel
> > development leaving ''official'' Xen kernels stuck on
2.6.28 which is
> > essentially useless for any modern distro. We had the choice between
trying
> > to finish off the paravirt_ops port, or dropping Xen entirely :-(
> 
> not criticising the choice (well, much anyway ;-) ) ...
> 
> rather, just hunting for options that work -- if even for the short(ish)
term
> 
> p.s. 2.6.28 a typo? that''s 2.6.18, no?
Yes, 2.6.18

Dan
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

On Wed, 2008-05-14 at 19:53 +0100, Daniel P. Berrange
wrote:
> Sadly that''s life with Xen.  Upstream Xen has basically stopped
all kernel
> development leaving ''official'' Xen kernels stuck on
2.6.28 which is
> essentially useless for any modern distro. We had the choice between trying
> to finish off the paravirt_ops port, or dropping Xen entirely :-(
What''s this?  Xen kernel development has stopped?  What does that mean
-
is the GPL project dead?

Regards,

Ranbir

-- 
Kanwar Ranbir Sandhu
Linux 2.6.22.14-72.fc6 i686 GNU/Linux 
22:02:27 up 31 days, 15:57, 2 users, load average: 1.03, 0.85, 0.84

Kanwar Ranbir Sandhu wrote:
> On Wed, 2008-05-14 at 19:53 +0100, Daniel P. Berrange wrote:
>   
>> Sadly that''s life with Xen.  Upstream Xen has basically
stopped all kernel
>> development leaving ''official'' Xen kernels stuck on
2.6.28 which is
>> essentially useless for any modern distro. We had the choice between
trying
>> to finish off the paravirt_ops port, or dropping Xen entirely :-(
>>     
>
> What''s this?  Xen kernel development has stopped?  What does that
mean -
> is the GPL project dead?
Not at all. 

In fact, I''d strongly disagree with Daniel''s characterisation
that Xen
has "stopped all kernel development" Redhat need to "finish
off" the
paravirt_ops port.  I''ve been working on it full time for the last 
couple of years, and have done the vast majority of the work needed to 
get paravirt_ops working.

Redhat have contributed valuable work in areas like the paravirtual 
framebuffer device, and are working on 64-bit and dom0 support.  But all 
of that is based on the work I''ve been doing on paravirt-ops 
infrastructure itself and the Xen implementation which uses it.

I''m still actively working on pvops/Xen, and currently focusing on 
bringing it up to feature parity with the old 2.6.18-xen patches.  In 
the last few weeks I''ve implemented balloon support, save/restore and 
starting work on pv-hvm driver support.

Meanwhile, open source Xen is also being actively developed by the 
original Xen developers and anyone who wishes to contribute.

    J

On Wed, May 28, 2008 at 11:32:12AM +0100, Jeremy Fitzhardinge
wrote:
> Kanwar Ranbir Sandhu wrote:
> >On Wed, 2008-05-14 at 19:53 +0100, Daniel P. Berrange wrote:
> >  
> >>Sadly that''s life with Xen.  Upstream Xen has basically
stopped all
> >>kernel development leaving ''official'' Xen kernels
stuck on 2.6.28 which is
> >>essentially useless for any modern distro. We had the choice
between
> >>trying
> >>to finish off the paravirt_ops port, or dropping Xen entirely :-(
> >>    
> >
> >What''s this?  Xen kernel development has stopped?  What does
that mean -
> >is the GPL project dead?
> 
> Not at all. 
> 
> In fact, I''d strongly disagree with Daniel''s
characterisation that Xen
> has "stopped all kernel development" Redhat need to "finish
off" the
> paravirt_ops port.  I''ve been working on it full time for the last
> couple of years, and have done the vast majority of the work needed to 
> get paravirt_ops working.
> 
> Redhat have contributed valuable work in areas like the paravirtual 
> framebuffer device, and are working on 64-bit and dom0 support.  But all 
> of that is based on the work I''ve been doing on paravirt-ops 
> infrastructure itself and the Xen implementation which uses it.
> 
Which reminds me that would be really nice to get a binary rpm for kernel-xen
with dom0 patches in it to try it and start reporting bugs.. :) 
> I''m still actively working on pvops/Xen, and currently focusing on
> bringing it up to feature parity with the old 2.6.18-xen patches.  In 
> the last few weeks I''ve implemented balloon support, save/restore
and
> starting work on pv-hvm driver support.
> 
This is really excellent news! Thanks a lot for doing this work. 

Hopefully we''ll see these features in rawhide/F10 kernel-xen soon :) 

-- Pasi

On Wed, May 28, 2008 at 11:32:12AM +0100, Jeremy Fitzhardinge
wrote:
> Kanwar Ranbir Sandhu wrote:
> >On Wed, 2008-05-14 at 19:53 +0100, Daniel P. Berrange wrote:
> >  
> >>Sadly that''s life with Xen.  Upstream Xen has basically
stopped all
> >>kernel development leaving ''official'' Xen kernels
stuck on 2.6.28 which is
> >>essentially useless for any modern distro. We had the choice
between
> >>trying
> >>to finish off the paravirt_ops port, or dropping Xen entirely :-(
> >>    
> >
> >What''s this?  Xen kernel development has stopped?  What does
that mean -
> >is the GPL project dead?
> 
> Not at all. 
> 
> In fact, I''d strongly disagree with Daniel''s
characterisation that Xen
> has "stopped all kernel development" Redhat need to "finish
off" the
> paravirt_ops port.  I''ve been working on it full time for the last
> couple of years, and have done the vast majority of the work needed to 
> get paravirt_ops working.
When I said ''stopped all kernel development'' I was referring
to the original
''linux-xen-2.6'' tree, which is what we''ve been
shipping in Fedora until this
point. Obviously paravirt_ops Xen development is still active & increasingly
so.

Regards,
Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

On Wed, May 28, 2008 at 03:51:10PM +0300, Pasi K?rkk?inen
wrote:
> On Wed, May 28, 2008 at 11:32:12AM +0100, Jeremy Fitzhardinge wrote:
> > Kanwar Ranbir Sandhu wrote:
> > >On Wed, 2008-05-14 at 19:53 +0100, Daniel P. Berrange wrote:
> > >  
> > >>Sadly that''s life with Xen.  Upstream Xen has
basically stopped all
> > >>kernel development leaving ''official'' Xen
kernels stuck on 2.6.28 which is
> > >>essentially useless for any modern distro. We had the choice
between
> > >>trying
> > >>to finish off the paravirt_ops port, or dropping Xen entirely
:-(
> > >>    
> > >
> > >What''s this?  Xen kernel development has stopped?  What
does that mean -
> > >is the GPL project dead?
> > 
> > Not at all. 
> > 
> > In fact, I''d strongly disagree with Daniel''s
characterisation that Xen
> > has "stopped all kernel development" Redhat need to
"finish off" the
> > paravirt_ops port.  I''ve been working on it full time for the
last
> > couple of years, and have done the vast majority of the work needed to
> > get paravirt_ops working.
> > 
> > Redhat have contributed valuable work in areas like the paravirtual 
> > framebuffer device, and are working on 64-bit and dom0 support.  But
all
> > of that is based on the work I''ve been doing on paravirt-ops 
> > infrastructure itself and the Xen implementation which uses it.
> > 
> 
> Which reminds me that would be really nice to get a binary rpm for
kernel-xen
> with dom0 patches in it to try it and start reporting bugs.. :) 
This is intended to go into rawhide sometime in the reasonably near
future, now that the critical F9 kerne-xen bugs have mostly been ironed
out. 

Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

On Wed, May 28, 2008 at 11:32:12AM +0100, Jeremy Fitzhardinge
wrote:
> Kanwar Ranbir Sandhu wrote:
> >On Wed, 2008-05-14 at 19:53 +0100, Daniel P. Berrange wrote:
> >  
> >>Sadly that''s life with Xen.  Upstream Xen has basically
stopped all
> >>kernel development leaving ''official'' Xen kernels
stuck on 2.6.28 which is
> >>essentially useless for any modern distro. We had the choice
between
> >>trying
> >>to finish off the paravirt_ops port, or dropping Xen entirely :-(
> >>    
> >
> >What''s this?  Xen kernel development has stopped?  What does
that mean -
> >is the GPL project dead?
> 
> Not at all. 
> 
> In fact, I''d strongly disagree with Daniel''s
characterisation that Xen
> has "stopped all kernel development" Redhat need to "finish
off" the
> paravirt_ops port.  I''ve been working on it full time for the last
> couple of years, and have done the vast majority of the work needed to 
> get paravirt_ops working.
> 
> Redhat have contributed valuable work in areas like the paravirtual 
> framebuffer device, and are working on 64-bit and dom0 support.  But all 
> of that is based on the work I''ve been doing on paravirt-ops 
> infrastructure itself and the Xen implementation which uses it.
> 
> I''m still actively working on pvops/Xen, and currently focusing on
> bringing it up to feature parity with the old 2.6.18-xen patches.  In 
> the last few weeks I''ve implemented balloon support, save/restore
and
> starting work on pv-hvm driver support.
> 
Btw is this work available in some repository? 

-- Pasi

Pasi Kärkkäinen wrote:
> Btw is this work available in some repository? 
>   
It''s in Ingo''s x86 git tree.  See 
http://people.redhat.com/mingo/tip.git/README for details.

    J

On Wed, May 28, 2008 at 09:08:35PM +0100, Jeremy Fitzhardinge
wrote:
> Pasi Kärkkäinen wrote:
> >Btw is this work available in some repository? 
> >  
> 
> It''s in Ingo''s x86 git tree.  See 
> http://people.redhat.com/mingo/tip.git/README for details.
> 
Ok. Thanks.

Is it 2.6.27 stuff, or is it already in 2.6.26? 

-- Pasi

Pasi Kärkkäinen wrote:
> On Wed, May 28, 2008 at 09:08:35PM +0100, Jeremy Fitzhardinge wrote:
>   
>> Pasi Kärkkäinen wrote:
>>     
>>> Btw is this work available in some repository? 
>>>  
>>>       
>> It''s in Ingo''s x86 git tree.  See 
>> http://people.redhat.com/mingo/tip.git/README for details.
>>
>>     
>
> Ok. Thanks.
>
> Is it 2.6.27 stuff, or is it already in 2.6.26? 
Most of it is targeted for .27.  Everything that''s planned for .26 is 
already in Linus'' tree.

    J