On Wed, Jan 23, 2008 at 09:06:14AM +1100, Rusty Russell wrote:
>
> > So this field is fine with me as long as it is named as such to
> > avoid confusion since it really has nothing to do with GSO as you
> > also need it for SG with large MTUs.
>
> Hmm, how about just "hdr_len" rather than "gso_hdr
On Tuesday 22 January 2008 21:36:30 Herbert Xu wrote:
> On Wed, Jan 16, 2008 at 03:19:03PM +1100, Rusty Russell wrote:
> > > > It's far easier to deal with GSO if we don't have to parse the packet
> > > > to figure out the header length. Add the field to the virtio_net_hdr
> > > > struct (and fix
Ingo Molnar wrote:
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
Maybe should this force-paravirt mode be a kernel debugging option?
No, just a plain CONFIG_PARAVIRT to turn it on and off independently
of everything else.
it should be a debugging option in the way that it's
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>> Maybe should this force-paravirt mode be a kernel debugging option?
>
> No, just a plain CONFIG_PARAVIRT to turn it on and off independently
> of everything else.
it should be a debugging option in the way that it's dependent on
KERNEL_DEBUG
With this, the paravirt_ops code can be enabled on x86_64 also.
Each guest implementation (Xen, VMI, lguest) now depends on X86_32. The
dependencies can be dropped for each one when they start to support
x86_64.
Signed-off-by: Eduardo Habkost <[EMAIL PROTECTED]>
---
arch/x86/Kconfig|
On Tue, Jan 22, 2008 at 09:55:41AM -0800, Jeremy Fitzhardinge wrote:
> Eduardo Pereira Habkost wrote:
> >If this is desirable for broader testing, we can make config PARAVIRT
> >visible and selectable on menuconfig, even when there is no guest
> >implementation being enabled. Should I do it?
> >
Eduardo Pereira Habkost wrote:
If this is desirable for broader testing, we can make config PARAVIRT
visible and selectable on menuconfig, even when there is no guest
implementation being enabled. Should I do it?
Yes please.
Maybe should this force-paravirt mode be a kernel debugging optio
On Tue, Jan 22, 2008 at 01:02:07PM +0100, Ingo Molnar wrote:
>
> * Eduardo Habkost <[EMAIL PROTECTED]> wrote:
>
> > This series contain fixes to make the paravirt_ops code compile and
> > boot on x86_64.
> >
> > This is a follow-up for the previous series from Glauber.
>
> thanks Eduardo, i've
* Glauber de Oliveira Costa <[EMAIL PROTECTED]> wrote:
> On Jan 18, 2008 8:02 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > * Zachary Amsden <[EMAIL PROTECTED]> wrote:
> >
> > > > but in exchange you broke all of 32-bit with CONFIG_PARAVIRT=y.
> > > > Which means you did not even build-test
* Eduardo Habkost <[EMAIL PROTECTED]> wrote:
> This series contain fixes to make the paravirt_ops code compile and
> boot on x86_64.
>
> This is a follow-up for the previous series from Glauber.
thanks Eduardo, i've applied your fixes.
could you perhaps send the missing bits that add the miss
On Wed, Jan 16, 2008 at 03:19:03PM +1100, Rusty Russell wrote:
> > > It's far easier to deal with GSO if we don't have to parse the packet
> > > to figure out the header length. Add the field to the virtio_net_hdr
> > > struct (and fix the spaces that somehow crept in there).
>
> > Why do we need
11 matches
Mail list logo
