Xen devel - Oct 2006 - reasons/requirements for some of patches/linux-2.6.16.29/*

Could anyone give a description (and reason it is needed for Xen, if
that''s
not obvious from the description) for each of

blktap-aio-16_03_06.patch
net-gso-*.patch
tpm_plugin_2.6.17.patch 

Thanks a lot, Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 6/10/06 8:25 am, "Jan Beulich" <jbeulich@novell.com> wrote:
> Could anyone give a description (and reason it is needed for Xen, if
that''s
> not obvious from the description) for each of
> 
> blktap-aio-16_03_06.patch
Not sure. Andrew Warfield or Julian Chesterfield probably will know. I would
guess it''s probably a backport of AIO changes from a more recent
kernel, but
I''m not certain about that.
> net-gso-*.patch
Backport of GSO patches from 2.6.17,18,... Done by Herbert Xu as part of his
big netfront/back reworking and upgrade. This will mostly go away when we
upgrade to 2.6.18.
> tpm_plugin_2.6.17.patch
IBM-requested backport of TPM changes in 2.6.17. This will go away when we
upgrade to 2.6.18.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 06.10.06 09:25
>>>
>On 6/10/06 8:25 am, "Jan Beulich" <jbeulich@novell.com>
wrote:
>
>> Could anyone give a description (and reason it is needed for Xen, if
that''s
>> not obvious from the description) for each of
>> 
>> blktap-aio-16_03_06.patch
>
>Not sure. Andrew Warfield or Julian Chesterfield probably will know. I would
>guess it''s probably a backport of AIO changes from a more recent
kernel, but
>I''m not certain about that.
It''s certainly not a backport (i.e. still needed in almost unchanged
form in 2.6.18).
>> net-gso-*.patch
>
>Backport of GSO patches from 2.6.17,18,... Done by Herbert Xu as part of his
>big netfront/back reworking and upgrade. This will mostly go away when we
>upgrade to 2.6.18.
I understand that. But what I need is an understanding of why Xen needs this
right away.
>> tpm_plugin_2.6.17.patch
>
>IBM-requested backport of TPM changes in 2.6.17. This will go away when we
>upgrade to 2.6.18.
Likewise here.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 6/10/06 08:51, "Jan Beulich" <jbeulich@novell.com> wrote:
>> Backport of GSO patches from 2.6.17,18,... Done by Herbert Xu as part
of his
>> big netfront/back reworking and upgrade. This will mostly go away when
we
>> upgrade to 2.6.18.
> 
> I understand that. But what I need is an understanding of why Xen needs
this
> right away.
It doesn''t. Netfront at least should compile without it. It would be
similarly easy to make netback do so too if it doesn''t already.
>>> tpm_plugin_2.6.17.patch
>> 
>> IBM-requested backport of TPM changes in 2.6.17. This will go away when
we
>> upgrade to 2.6.18.
> 
> Likewise here.
I don''t know if Xen-specific drivers in the sparse tree depend on that
patch. Stefan Berger will know better than me (cc''ed).

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, Oct 06, 2006 at 08:51:28AM +0100, Jan Beulich
wrote:
> >>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 06.10.06 09:25
>>>
> >On 6/10/06 8:25 am, "Jan Beulich" <jbeulich@novell.com>
wrote:
> >
> >> Could anyone give a description (and reason it is needed for Xen,
if that''s
> >> not obvious from the description) for each of
> >> 
> >> blktap-aio-16_03_06.patch
> >
> >Not sure. Andrew Warfield or Julian Chesterfield probably will know. I
would
> >guess it''s probably a backport of AIO changes from a more
recent kernel, but
> >I''m not certain about that.
> 
> It''s certainly not a backport (i.e. still needed in almost
unchanged form in 2.6.18).
> 
> >> net-gso-*.patch
> >
> >Backport of GSO patches from 2.6.17,18,... Done by Herbert Xu as part
of his
> >big netfront/back reworking and upgrade. This will mostly go away when
we
> >upgrade to 2.6.18.
> 
> I understand that. But what I need is an understanding of why Xen needs
this
> right away.
A significant performance increase. Without it, DomU -> Dom0 networking is
far
less than baremetal wirespeed; With it, DomU -> Dom0 networking has parity
with baremetal wirespeed. Herbert''s preso at the summit had a few more
details

  http://xensource.com/files/summit_3/rdd-tso-xen.pdf

Regards,
Dan
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote on 10/06/2006 04:17:12 AM:
> On 6/10/06 08:51, "Jan Beulich" <jbeulich@novell.com>
wrote:
> 
> >>> tpm_plugin_2.6.17.patch
> >> 
> >> IBM-requested backport of TPM changes in 2.6.17. This will go away
when we
> >> upgrade to 2.6.18.
> > 
> > Likewise here.
> 
> I don''t know if Xen-specific drivers in the sparse tree depend on
that
> patch. Stefan Berger will know better than me (cc''ed).
Plain 2.6.16 gives the following function in tpm.c:

int              tpm_register_hardware(struct device *dev, struct 
tpm_vendor_specific *entry)

2.6.17 offers the following signature:

struct tpm_chip *tpm_register_hardware(struct device *dev, const struct 
tpm_vendor_specific *entry)

I adopted this from 2.6.17 since I needed to have access to the tpm_chip 
structure where I could store other driver-specific information in. Of 
course all plugin drivers use this function and therefore the 
tpm_plugin_2.6.17.patch exists.

  Stefan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > Could anyone give a description (and reason it is needed for Xen, if
that''s
> > not obvious from the description) for each of
> >
> > blktap-aio-16_03_06.patch
>
> Not sure. Andrew Warfield or Julian Chesterfield probably will know. I
would
> guess it''s probably a backport of AIO changes from a more recent
kernel, but
> I''m not certain about that.
The patch allows polling of aio and non-aio file descriptors through a
single call.  It''s a stopgap that was sent to the aio devel list and
is there in anticipation of a solution for mixed polling in linux.

The old approach was to have a separate thread to call aio_getevents
and signal that to the main poll loop through a pipe -- it''s no less
ugly, but keeps changes to user space at a cost in performance.

a.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi,

On Fri, 2006-10-06 at 08:25 +0100, Jan Beulich wrote:
> Could anyone give a description (and reason it is needed for Xen, if
that''s
> not obvious from the description) for each of
> 
> blktap-aio-16_03_06.patch
The blktap userland server (tapdisk) submits IO requests via kernel AIO,
but also waits for network/evtchn events via file descriptors.  And
alas, the kernel has no way to wait for AIO and fd wakeups in a single
syscall.

This patch implements aio-for-poll --- it''s a new core kernel ABI which
allows a temporary fd to be associated with an AIO IO context, so you
can wait on AIO and normal fds via a single select() call.  But this ABI
has been vetoed upstream.

Upstream has given initial approval to an alternative means whereby
instead of submitting a poll() for AIO, you submit an AIO request for
poll.  Then, io_getevents() can wait for both fd and AIO activity.  But
that functionality is still not upstream.

We did not want to include the non-approved AIO+poll mechanism in our
own Fedora kernels, so as a workaround, I''ve coded up a simple patch
which makes tapdisk spawn a separate thread for AIO events, and return
wakeups via a pipe fd to the main event loop when AIO arrives.  That
works fine as a temporary measure to allow us to ship blktap without the
AIO/poll stuff resolved upstream; but longer term, Jeff Moyer has been
talking to the AIO people to get epoll-for-AIO merged.  I''m not sure of
the status of that work though, it may well have stalled.

I can post the AIO-thread patch here if anyone''s interested; I
didn''t
post it as part of my recent blktap changes because (a) Xen upstream
doesn''t need it, it carries the aio-for-poll patch instead; and (b) the
_right_ answer for Xen is eventually to use an upstream-blessed poll-
for-aio patch instead.

Cheers,
 Stephen



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Jan Beulich <jbeulich@novell.com> wrote:
>
> It''s certainly not a backport (i.e. still needed in almost
unchanged form in 2.6.18).
> 
>>> net-gso-*.patch
>>
>>Backport of GSO patches from 2.6.17,18,... Done by Herbert Xu as part of
his
>>big netfront/back reworking and upgrade. This will mostly go away when
we
>>upgrade to 2.6.18.
Because TSO is enabled by default in netfront.  Without this you won''t
have external communications if your physical NIC driver does not support
TSO.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel