Re: [PATCH 2/3] virtio: Net header needs gso_hdr_len
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 this? When receiving GSO packets from an untrusted
> > source the network stack will fill in the transport header offset
> > after verifying that the headers are sane.
>
> Thanks for clarifying; it simplifies things.
Actually now that I've tried your test program I can see that this
field exists not because of GSO, but because of SG. It tells you
how many bytes you want to put in the skb head as opposed to the
frag array.
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.
I think this is more flexible than the Xen approach where this is
essentially hard-coded to 64 bytes.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/4] paravirt_ops-64 compile fixes
* 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 missing 64-bit Kconfig entries? Even if the 64-bit side is not functional yet as a real guest, it would help us find the build bugs and any runtime regressions PARAVIRT might cause on the native 64-bit side of the kernel. Or is it now just a matter of removing all the depends-on X86_32 bits in arch/x86/Kconfig? Ingo ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/10] Tree fixes for PARAVIRT
* 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 it on 32-bit, let alone boot > > > > test it... > > > > > > Why are we rushing so much to do 64-bit paravirt that we are breaking > > > working configurations? If the developement is going to be this > > > chaotic, it should be done and tested out of tree until it can > > > stabilize. > > > > what you see is a open feedback cycle conducted on lkml. People send > > patches for arch/x86, and we tell them if it breaks something. The bug > > was found before i pushed out the x86.git devel tree (and the fix is > > below - but this shouldnt matter to you because the bug never hit a > > public x86.git tree). > > > > Ingo > > > Other than this, it seems to build and boot fine. > > Do you want me to resend ? no, this was the only small problem i found, your series looks good to me and is included in latest x86.git. Ingo ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/4] paravirt_ops-64 compile fixes
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 applied your fixes. > > could you perhaps send the missing bits that add the missing 64-bit > Kconfig entries? Even if the 64-bit side is not functional yet as a real > guest, it would help us find the build bugs and any runtime regressions > PARAVIRT might cause on the native 64-bit side of the kernel. > > Or is it now just a matter of removing all the depends-on X86_32 bits in > arch/x86/Kconfig? Removing the depends won't be enough because CONFIG_PARAVIRT won't be selected unless one of Xen, VMI, or lguest is selected. (PARAVIRT is not visible on menuconfig, only PARAVIRT_GUEST, that doesn't enable any code). When hacking, I remove the 32-bit depends and add "select PARAVIRT" to "menuconfig PARAVIRT_GUEST". I think neither of the three guest implementations are ready for 64-bit yet. I am working on Xen and it is far from being ready for inclusion. I don't know about VMI and lguest. 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? Maybe should this force-paravirt mode be a kernel debugging option? -- Eduardo ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/4] paravirt_ops-64 compile fixes
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 option? No, just a plain CONFIG_PARAVIRT to turn it on and off independently of everything else. J ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
[PATCH 1/2] Allow enabling PARAVIRT without any guest implementation
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? > > > > Yes please. > This will allow people to enable the paravirt_ops code even when no guest support is enabled, for broader testing of the paravirt_ops code. Signed-off-by: Eduardo Habkost <[EMAIL PROTECTED]> --- arch/x86/Kconfig | 18 +- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 4e910d8..715bbcd 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -325,15 +325,6 @@ config SCHED_NO_NO_OMIT_FRAME_POINTER If in doubt, say "Y". -config PARAVIRT - bool - depends on X86_32 && !(X86_VISWS || X86_VOYAGER) - help - This changes the kernel so it can modify itself when it is run - under a hypervisor, potentially improving performance significantly - over full virtualization. However, when run without a hypervisor - the kernel is theoretically slower and slightly larger. - menuconfig PARAVIRT_GUEST bool "Paravirtualized guest support" depends on X86_32 @@ -359,6 +350,15 @@ config VMI source "arch/x86/lguest/Kconfig" +config PARAVIRT + bool "Enable paravirtualization code" + depends on X86_32 && !(X86_VISWS || X86_VOYAGER) + help + This changes the kernel so it can modify itself when it is run + under a hypervisor, potentially improving performance significantly + over full virtualization. However, when run without a hypervisor + the kernel is theoretically slower and slightly larger. + endif config ACPI_SRAT -- 1.5.3.4 -- Eduardo ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
[PATCH 2/2] Remove depends on X86_32 from PARAVIRT & PARAVIRT_GUEST
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|4 ++-- arch/x86/lguest/Kconfig |1 + arch/x86/xen/Kconfig|1 + 3 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 715bbcd..43d535a 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -327,7 +327,6 @@ config SCHED_NO_NO_OMIT_FRAME_POINTER menuconfig PARAVIRT_GUEST bool "Paravirtualized guest support" - depends on X86_32 help Say Y here to get to see options related to running Linux under various hypervisors. This option alone does not add any kernel code. @@ -341,6 +340,7 @@ source "arch/x86/xen/Kconfig" config VMI bool "VMI Guest support" select PARAVIRT + depends on X86_32 depends on !(X86_VISWS || X86_VOYAGER) help VMI provides a paravirtualized interface to the VMware ESX server @@ -352,7 +352,7 @@ source "arch/x86/lguest/Kconfig" config PARAVIRT bool "Enable paravirtualization code" - depends on X86_32 && !(X86_VISWS || X86_VOYAGER) + depends on !(X86_VISWS || X86_VOYAGER) help This changes the kernel so it can modify itself when it is run under a hypervisor, potentially improving performance significantly diff --git a/arch/x86/lguest/Kconfig b/arch/x86/lguest/Kconfig index 19626ac..964dfa3 100644 --- a/arch/x86/lguest/Kconfig +++ b/arch/x86/lguest/Kconfig @@ -1,6 +1,7 @@ config LGUEST_GUEST bool "Lguest guest support" select PARAVIRT + depends on X86_32 depends on !X86_PAE depends on !(X86_VISWS || X86_VOYAGER) select VIRTIO diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig index fbfa55c..4d5f264 100644 --- a/arch/x86/xen/Kconfig +++ b/arch/x86/xen/Kconfig @@ -5,6 +5,7 @@ config XEN bool "Xen guest support" select PARAVIRT + depends on X86_32 depends on X86_CMPXCHG && X86_TSC && !NEED_MULTIPLE_NODES && !(X86_VISWS || X86_VOYAGER) help This is the Linux Xen port. Enabling this will allow the -- 1.5.3.4 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/4] paravirt_ops-64 compile fixes
* 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 and KERNEL_EXPERIMENTAL. i dont think you shold worry about this - i think 64-bit guest support for specific hypervisors could be added even after the merge window, if it's reasonably isolated (which i'd expect it to be). It clearly cannot break anything else so it's the same category as new driver or new hardware support - more relaxed integration rules. Then we can remove the KERNEL_DEBUG and KERNEL_EXPERIMENTAL dependency as well. Ingo ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/4] paravirt_ops-64 compile fixes
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 dependent on KERNEL_DEBUG and KERNEL_EXPERIMENTAL. EXPERIMENTAL certainly, but not DEBUG. Sure, CONFIG_PARAVIRT is somewhat useless if you don't also configure Xen/lguest/etc, but running a paravirt system on bare hardware will probably be the most common way a paravirt kernel gets run (a distro will always enable it and compile in whatever hypervisor support they want, but most people will end up just running it on bare hardware). Therefore, we should try to be as sure as possible that PARAVIRT works well (ie, indistinguishable from non-PARAVIRT) on bare hardware. i dont think you shold worry about this - i think 64-bit guest support for specific hypervisors could be added even after the merge window, if it's reasonably isolated (which i'd expect it to be). It clearly cannot break anything else so it's the same category as new driver or new hardware support - more relaxed integration rules. Then we can remove the KERNEL_DEBUG and KERNEL_EXPERIMENTAL dependency as well. Good, I'm glad you feel that way. J ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH 2/3] virtio: Net header needs gso_hdr_len
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 the spaces that somehow crept in there). > > > > > > Why do we need this? When receiving GSO packets from an untrusted > > > source the network stack will fill in the transport header offset > > > after verifying that the headers are sane. > > > > Thanks for clarifying; it simplifies things. > > Actually now that I've tried your test program I can see that this > field exists not because of GSO, but because of SG. It tells you > how many bytes you want to put in the skb head as opposed to the > frag array. Yes, I took it out after your comments, then realized I needed it and put it back. > 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_len"? Thanks, Rusty. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH 2/3] virtio: Net header needs gso_hdr_len
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_len"?
Sounds fine to me.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
