Xen devel - Oct 2006 - [PATCH][RESEND] PV drivers for HVM guests

I am enclosing the patch I have been working on. I have tested this on sles9
(2.6.5) and RHEL 4 (2.6.9). The patch applies cleanly on ChangeSet 11635. This
patch was cleaned up based on Ian''s and DOI''s work.

Signed-off-by: K. Y. Srinivasan (ksrinivasan@novell.com)




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

Hi,

You (ksrinivasan) said:
> I am enclosing the patch I have been working on. I have tested this on
> sles9 (2.6.5) and RHEL 4 (2.6.9). The patch applies cleanly on ChangeSet
> 11635. This patch was cleaned up based on Ian''s and DOI''s
work.
> 
> Signed-off-by: K. Y. Srinivasan (ksrinivasan@novell.com)
 The patch seems that the source files of unmodified_drivers are split
from linux-2.6-xen-sparse, I think.

  I think it because ...
> diff -Nur unmodified_drivers/linux-2.6/blkfront/blkfront.c
unmodified_drivers_new/linux-2.6/blkfront/blkfront.c
> --- unmodified_drivers/linux-2.6/blkfront/blkfront.c	2006-10-04
00:38:41.000000000 -0400
> +++ unmodified_drivers_new/linux-2.6/blkfront/blkfront.c	2006-10-13
11:11:43.000000000 -0400
and
> @@ -47,6 +47,7 @@
>  #include <xen/gnttab.h>
>  #include <asm/hypervisor.h>
>  #include <asm/maddr.h>
> +#include <xen/platform_compat.h>
>  
>  #define BLKIF_STATE_DISCONNECTED 0
>  #define BLKIF_STATE_CONNECTED    1
  xen/platform_compat.h is introduced, but it exists in unmodified_drviers
except linux-2.6-xen-sparse.

  Am I true ?

Thanks,
- Tsunehisa Doi

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

We intend  to maintain the source for the unmodified drivers separately in our
source tree. The idea is that this will track the official xen source tree; we
would apply the patch to target this source for a particular unmodified guest
target. This would eliminate the need to carry the compatibility baggage in the
pristine unmodified driver code.

Regards,

K. Y 
>>> On Wed, Oct 18, 2006 at  7:56 PM, in message
<200610182356.k9INuAF03840@photon.sky.yk.fujitsu.co.jp>,
<Doi.Tsunehisa@jp.fujitsu.com> wrote: 
> Hi,
> 
> You (ksrinivasan) said:
>> I am enclosing the patch I have been working on. I have tested this on
>> sles9 (2.6.5) and RHEL 4 (2.6.9). The patch applies cleanly on
ChangeSet
>> 11635. This patch was cleaned up based on Ian''s and
DOI''s work.
>> 
>> Signed- off- by: K. Y. Srinivasan (ksrinivasan@novell.com)
> 
>  The patch seems that the source files of unmodified_drivers are split
> from linux- 2.6- xen- sparse, I think.
> 
>   I think it because ...
> 
>> diff - Nur unmodified_drivers/linux- 2.6/blkfront/blkfront.c 
> unmodified_drivers_new/linux- 2.6/blkfront/blkfront.c
>> ---  unmodified_drivers/linux- 2.6/blkfront/blkfront.c	2006- 10- 04
00:38:41.000000000
> - 0400
>> +++ unmodified_drivers_new/linux- 2.6/blkfront/blkfront.c	2006- 10- 13 
> 11:11:43.000000000 - 0400
> 
> and
> 
>> @@ - 47,6 +47,7 @@
>>  #include <xen/gnttab.h>
>>  #include <asm/hypervisor.h>
>>  #include <asm/maddr.h>
>> +#include <xen/platform_compat.h>
>>  
>>  #define BLKIF_STATE_DISCONNECTED 0
>>  #define BLKIF_STATE_CONNECTED    1
> 
>   xen/platform_compat.h is introduced, but it exists in unmodified_drviers
> except linux- 2.6- xen- sparse.
> 
>   Am I true ?
> 
> Thanks,
> -  Tsunehisa Doi

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

Hi,

You (ksrinivasan) said:
> We intend  to maintain the source for the unmodified drivers separately
> in our source tree. The idea is that this will track the official xen
> source tree; we would apply the patch to target this source for a
> particular unmodified guest target. This would eliminate the need to
> carry the compatibility baggage in the pristine unmodified driver code.
  I understand that it has to be separated from xen source tree for
maintenacne as products. But I think that we should avoid to fork the
source tree. Because its code structure is not stable, I think.

  What do you think about ?

Thanks,
- Tsunehisa Doi

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

>>> On Fri, Oct 20, 2006 at  6:12 AM, in message
<200610201012.k9KACIF29714@photon.sky.yk.fujitsu.co.jp>,
<Doi.Tsunehisa@jp.fujitsu.com> wrote: 
> Hi,
> 
> You (ksrinivasan) said:
>> We intend  to maintain the source for the unmodified drivers separately
>> in our source tree. The idea is that this will track the official xen
>> source tree; we would apply the patch to target this source for a
>> particular unmodified guest target. This would eliminate the need to
>> carry the compatibility baggage in the pristine unmodified driver code.
> 
>   I understand that it has to be separated from xen source tree for
> maintenacne as products. But I think that we should avoid to fork the
> source tree. Because its code structure is not stable, I think.
> 
>   What do you think about ?
We are not forking tree. The pristine PV driver code will always be the exact
code in the xen source tree.

Regards,

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

Hi,

You (ksrinivasan) said:
>>   I understand that it has to be separated from xen source tree for
>> maintenacne as products. But I think that we should avoid to fork the
>> source tree. Because its code structure is not stable, I think.
>> 
>>   What do you think about ?
> 
> We are not forking tree. The pristine PV driver code will always be the
> exact code in the xen source tree. 
  Sorry, My explaining seems to be bad.

  My opinion is that unmodified_drivers tree should not be forked from
linux-sparse tree. Because its code structure will be changed from now
on, so we will have to follow.

Thanks,
- Tsunehisa Doi

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

Hi all,

"Ky Srinivasan" <ksrinivasan@novell.com>
wrote:
> I am enclosing the patch I have been working on. I have tested this on
> sles9 (2.6.5) and RHEL 4 (2.6.9). The patch applies cleanly on
> ChangeSet 11635. This patch was cleaned up based on Ian''s and
DOI''s
> work.
  I merged Srinivasan''s work and a part of modification for IA64
platform.

  I tested only compiling on RHEL4 Update 2.

Thanks,
- Tsunehisa Doi



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

On Tue, 2006-10-24 at 11:54 +0900, DOI Tsunehisa wrote:
> Hi all,
> 
> "Ky Srinivasan" <ksrinivasan@novell.com> wrote:
> > I am enclosing the patch I have been working on. I have tested this on
> > sles9 (2.6.5) and RHEL 4 (2.6.9). The patch applies cleanly on
> > ChangeSet 11635. This patch was cleaned up based on Ian''s and
DOI''s
> > work.
> 
> I merged Srinivasan''s work and a part of modification for IA64
> platform.
Thank you. I am just in the process of cleaning up the patch and
breaking it into manageable chunks. I''ve incorporated changes from your
patches and added both your signed-off-by''s to the bits you''ve
signed
off on.
> I tested only compiling on RHEL4 Update 2.
OK, I''m boot testing on sles9sp3 and rhel4.4. Perhaps that explains
some
of the extra bits you seem to have which I don''t seem to need? Or
perhaps they are IA64 specific?

I''ve left the bits that I''ve quoted below out for now since I
didn''t
need them for the releases I''m testing. Once I''ve committed
the first
batch we can revisit these as well as anything I''ve dropped by mistake.

Cheers,
Ian.
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/unmodified_drivers/linux-2.6/compat-include/compat.h	Tue Oct 24
11:00:08 2006 +0900
> +#if defined(__LINUX_COMPILER_H) && !defined(__nocast)
> +#define __nocast
> +#endif
> +#if defined(_LINUX_SCHED_H) && !defined(__sched)
> +#define __sched
> +#endif
> +#if defined(_LINUX_TYPES_H) && LINUX_VERSION_CODE <
KERNEL_VERSION(2,6,14)
> +typedef unsigned __nocast gfp_t;
> +#endif
> +#if defined(_LINUX_ERR_H) && LINUX_VERSION_CODE <
KERNEL_VERSION(2,6,12)
> +#define IS_ERR_VALUE(x) unlikely((x) > (unsigned long)-1000L)
> +#endif
> +#if defined(__ia64__) && LINUX_VERSION_CODE <
KERNEL_VERSION(2,6,11)
> +#include <asm-generic/pgtable-nopud.h>
> +#endif


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

Hi Ian,

You (Ian.Campbell) said:
>> I tested only compiling on RHEL4 Update 2.
> 
> OK, I''m boot testing on sles9sp3 and rhel4.4. Perhaps that
explains some
> of the extra bits you seem to have which I don''t seem to need? Or
> perhaps they are IA64 specific?
  In my patch, IA64 specfic part is below.
>> +#if defined(__ia64__) && LINUX_VERSION_CODE <
KERNEL_VERSION(2,6,11)
>> +#include <asm-generic/pgtable-nopud.h>
>> +#endif
Thanks,
- Tsunehisa Doi

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

Hi Ian,

I (Doi.Tsunehisa) said:
> You (Ian.Campbell) said:
>> OK, I''m boot testing on sles9sp3 and rhel4.4.
  I''ve met a compile error about gfp_t in rhel4.4. Thus, I avoided to
meet
the compile error with preliminary patch like below.

Thanks,
- Tsunehisa Doi

  
diff -r 5b9bf5501157 -r 1b7b292278d0
unmodified_drivers/linux-2.6/compat-include/compat.h
--- a/unmodified_drivers/linux-2.6/compat-include/compat.h      Tue Oct 24
09:25:24 2006 +0900
+++ b/unmodified_drivers/linux-2.6/compat-include/compat.h      Tue Oct 24
17:55:16 2006 +0900
@@ -31,7 +31,8 @@
 #define __sched
 #endif

-#if defined(_LINUX_TYPES_H) && LINUX_VERSION_CODE <
KERNEL_VERSION(2,6,14)
+#if defined(_LINUX_TYPES_H) && LINUX_VERSION_CODE <
KERNEL_VERSION(2,6,14) \
+    && !defined(HAVE_GFP_T)
 typedef unsigned __nocast gfp_t;
 #endif

diff -r 5b9bf5501157 -r 1b7b292278d0 unmodified_drivers/linux-2.6/overrides.mk
--- a/unmodified_drivers/linux-2.6/overrides.mk Tue Oct 24 09:25:24 2006 +0900
+++ b/unmodified_drivers/linux-2.6/overrides.mk Tue Oct 24 17:55:16 2006 +0900
@@ -10,3 +10,6 @@ EXTRA_CFLAGS += -DCONFIG_XEN_NETDEV_GRAN
 EXTRA_CFLAGS += -DCONFIG_XEN_NETDEV_GRANT_RX -DCONFIG_XEN_NETDEV_GRANT_TX
 EXTRA_CFLAGS += -D__XEN_INTERFACE_VERSION__=0x00030202
 EXTRA_CFLAGS += -I$(M)/include -I$(M)/compat-include -DHAVE_COMPAT_H
+ifeq ($(KERNELRELEASE),2.6.9-42.EL) # for RHEL4 U4
+    EXTRA_CFLAGS += -DHAVE_GFP_T
+endif

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

On Wed, 2006-10-25 at 12:11 +0900, Doi.Tsunehisa@jp.fujitsu.com
wrote:
>   I''ve met a compile error about gfp_t in rhel4.4. Thus, I avoided
to meet
> the compile error with preliminary patch like below.
Oh, you mean you were seeing problems because gfp_t is backported to
RHEL 4.4? I thought your patch was adding the typedef but actually you
are conditionally removing it.

I not sure the typedef is needed at all -- nothing in unmodified_drivers
uses gpf_t as far as I can see. My current patchset doesn''t define it
at
all and builds ok on RHEL4.4. Perhaps it is an arch specific issue?

Cheers,
Ian.


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

On Wed, 2006-10-25 at 08:54 +0900, Doi.Tsunehisa@jp.fujitsu.com
wrote:
>   In my patch, IA64 specfic part is below.
> 
> >> +#if defined(__ia64__) && LINUX_VERSION_CODE <
KERNEL_VERSION(2,6,11)
> >> +#include <asm-generic/pgtable-nopud.h>
> >> +#endif
Can we come up with a more specific guard? Does something like this work
for you?
	#if defined _ASM_IA64_PGTABLE_H && !defined(_PGTABLE_NOPUD_H)

Cheers,
Ian.



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

You (Ian.Campbell) said:
>>   I''ve met a compile error about gfp_t in rhel4.4. Thus, I
avoided to meet
>> the compile error with preliminary patch like below.
> 
> Oh, you mean you were seeing problems because gfp_t is backported to
> RHEL 4.4? I thought your patch was adding the typedef but actually you
> are conditionally removing it.
> 
> I not sure the typedef is needed at all -- nothing in unmodified_drivers
> uses gpf_t as far as I can see. My current patchset doesn''t define
it at
> all and builds ok on RHEL4.4. Perhaps it is an arch specific issue?
  Sorry, I might be confused. I''ll check it.

Thanks,
- Tsunehisa Doi

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

Hi Ian,

You (Ian.Campbell) said:
>>   In my patch, IA64 specfic part is below.
>> 
>>>> +#if defined(__ia64__) && LINUX_VERSION_CODE <
KERNEL_VERSION(2,6,11)
>>>> +#include <asm-generic/pgtable-nopud.h>
>>>> +#endif
> 
> Can we come up with a more specific guard? Does something like this work
> for you?
> 	#if defined _ASM_IA64_PGTABLE_H && !defined(_PGTABLE_NOPUD_H)
  Ok. I''ll try it.

Thanks,
- Tsunehisa Doi

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

Hi Ian,

I (Doi.Tsunehisa) said:
>> I not sure the typedef is needed at all -- nothing in
unmodified_drivers
>> uses gpf_t as far as I can see. My current patchset doesn''t
define it at
>> all and builds ok on RHEL4.4. Perhaps it is an arch specific issue?
> 
>   Sorry, I might be confused. I''ll check it.
  I''ve checked it. It''s an ia64 arch specific issue indeed.

Thanks,
- Tsunehisa Doi

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

Hi Ian,

I (Doi.Tsunehisa) said:
>   I''ve checked it. It''s an ia64 arch specific issue
indeed.
  BTW, I might find a issue about NET_IP_ALIGN in the compatible shim.
Currentry, its value is 0, but the value should be matched a value of
netback module. Thus, its value should be 2, I think.

  What do you think about the issue ?

Thanks,
- Tsunehisa Doi

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

On Thu, 2006-10-26 at 12:58 +0900, Doi.Tsunehisa@jp.fujitsu.com
wrote:
> I (Doi.Tsunehisa) said:
> >> I not sure the typedef is needed at all -- nothing in
unmodified_drivers
> >> uses gpf_t as far as I can see. My current patchset
doesn''t define it at
> >> all and builds ok on RHEL4.4. Perhaps it is an arch specific
issue?
> > 
> >   Sorry, I might be confused. I''ll check it.
> 
>   I''ve checked it. It''s an ia64 arch specific issue
indeed.
I''d much prefer it if we can find a way to avoid encoding specific RHEL
kernel versions as you had in your patch. I''ve gone with
	#define gfp_t unsigned
which basically ignores any existing typedef. I think this is OK in this
instance since gfp_t has always been 

On Thu, 2006-10-26 at 15:37 +0900, Doi.Tsunehisa@jp.fujitsu.com wrote:
>   BTW, I might find a issue about NET_IP_ALIGN in the compatible shim.
> Currentry, its value is 0, but the value should be matched a value of
> netback module. Thus, its value should be 2, I think.
> 
>   What do you think about the issue ?
My thinking was that since those older kernels don''t define
NET_IP_ALIGN
and don''t hardcode the number 2 anywhere they don''t expect any
extra
alignment. Therefore using 0 seems correct in terms of behaving the same
as native drivers do on those versions. I''m not sure I would want to
backport the addition of the extra padding in our drivers, the distros
haven''t seen the need for example...

My current patch is below, it cross-compiles for IA64 without warnings
against RHEL4.4 and SLES9sp3. Could you let me know if it works for you?
If so would you mind submitting the ia64 bits via the ia64 maintainer.
I''ll apply the unmodified_drivers bits.

Ian.

Additional PV-on-HVM fixes for IA64.

Signed-off-by: Ian Campbell <ian.campbell@xensource.com>

diff -r a0a65da68861 linux-2.6-xen-sparse/arch/ia64/xen/xencomm.c
--- a/linux-2.6-xen-sparse/arch/ia64/xen/xencomm.c	Thu Oct 26 12:27:51 2006
+0100
+++ b/linux-2.6-xen-sparse/arch/ia64/xen/xencomm.c	Thu Oct 26 15:06:15 2006
+0100
@@ -20,6 +20,11 @@
 #include <linux/mm.h>
 #include <xen/interface/xen.h>
 #include <asm/page.h>
+
+#ifdef HAVE_XEN_PLATFORM_COMPAT_H
+#include <xen/platform-compat.h>
+#endif
+
 #include <asm/xen/xencomm.h>
 
 static int xencomm_debug = 0;
diff -r a0a65da68861 linux-2.6-xen-sparse/include/asm-ia64/hypercall.h
--- a/linux-2.6-xen-sparse/include/asm-ia64/hypercall.h	Thu Oct 26 12:27:51 2006
+0100
+++ b/linux-2.6-xen-sparse/include/asm-ia64/hypercall.h	Thu Oct 26 15:06:15 2006
+0100
@@ -283,6 +283,9 @@ static inline void exit_idle(void) {}
 #ifdef CONFIG_XEN
 #include <asm/xen/privop.h>
 #endif /* CONFIG_XEN */
+#ifdef HAVE_XEN_PLATFORM_COMPAT_H
+#include <xen/platform-compat.h>
+#endif
 
 static inline unsigned long
 __HYPERVISOR_ioremap(unsigned long ioaddr, unsigned long size)
diff -r a0a65da68861 linux-2.6-xen-sparse/include/asm-ia64/hypervisor.h
--- a/linux-2.6-xen-sparse/include/asm-ia64/hypervisor.h	Thu Oct 26 12:27:51
2006 +0100
+++ b/linux-2.6-xen-sparse/include/asm-ia64/hypervisor.h	Thu Oct 26 15:06:15
2006 +0100
@@ -56,8 +56,8 @@ extern int running_on_xen;
 #include <xen/interface/event_channel.h>
 #include <xen/interface/physdev.h>
 #include <xen/interface/sched.h>
+#include <asm/ptrace.h>
 #include <asm/hypercall.h>
-#include <asm/ptrace.h>
 #include <asm/page.h>
 
 extern shared_info_t *HYPERVISOR_shared_info;
diff -r a0a65da68861
unmodified_drivers/linux-2.6/compat-include/asm-generic/pgtable-nopud.h
--- a/unmodified_drivers/linux-2.6/compat-include/asm-generic/pgtable-nopud.h
Thu Oct 26 12:27:51 2006 +0100
+++ b/unmodified_drivers/linux-2.6/compat-include/asm-generic/pgtable-nopud.h
Thu Oct 26 15:06:15 2006 +0100
@@ -9,6 +9,7 @@
 #define pud_offset(d, va)     d
 #define pud_none(pud)         0
 #define pud_present(pud)      1
+#define pud_bad(pud)          0
 #define PTRS_PER_PUD          1
 
 #endif /* _PGTABLE_NOPUD_H */
diff -r a0a65da68861
unmodified_drivers/linux-2.6/compat-include/xen/platform-compat.h
--- a/unmodified_drivers/linux-2.6/compat-include/xen/platform-compat.h	Thu Oct
26 12:27:51 2006 +0100
+++ b/unmodified_drivers/linux-2.6/compat-include/xen/platform-compat.h	Thu Oct
26 15:06:15 2006 +0100
@@ -25,6 +25,21 @@
 #define NET_IP_ALIGN 0
 #endif
 
+#if defined(_LINUX_ERR_H) && !defined(IS_ERR_VALUE)
+#define IS_ERR_VALUE(x) unlikely((x) > (unsigned long)-1000L)
+#endif
+
+#if defined(_ASM_IA64_PGTABLE_H) && !defined(_PGTABLE_NOPUD_H)
+#include <asm-generic/pgtable-nopud.h>
+#endif
+
+/* Some kernels have this typedef backported so we cannot reliably
+ * detect based on version number, hence we forcibly #define it.
+ */
+#if defined(__LINUX_TYPES_H) || defined(__LINUX_GFP_H)
+#define gfp_t unsigned
+#endif
+
 #if defined(_LINUX_FS_H) && LINUX_VERSION_CODE <
KERNEL_VERSION(2,6,9)
 #define nonseekable_open(inode, filp) /* Nothing to do */
 #endif
diff -r a0a65da68861 unmodified_drivers/linux-2.6/mkbuildtree



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

Hi Ian,

You (Ian.Campbell) said:
> I''d much prefer it if we can find a way to avoid encoding specific
RHEL
> kernel versions as you had in your patch. I''ve gone with
> 	#define gfp_t unsigned
> which basically ignores any existing typedef. I think this is OK in this
> instance since gfp_t has always been 
   .....
> My current patch is below, it cross-compiles for IA64 without warnings
> against RHEL4.4 and SLES9sp3. Could you let me know if it works for you?
> If so would you mind submitting the ia64 bits via the ia64 maintainer.
> I''ll apply the unmodified_drivers bits.
  Takanori (he is my co-worker) checked this patch, but it occures
compile error in linux-xen. We are investigating it.
>>   BTW, I might find a issue about NET_IP_ALIGN in the compatible shim.
>> Currentry, its value is 0, but the value should be matched a value of
>> netback module. Thus, its value should be 2, I think.
>> 
>>   What do you think about the issue ?
>
> My thinking was that since those older kernels don''t define
NET_IP_ALIGN
> and don''t hardcode the number 2 anywhere they don''t
expect any extra
> alignment. Therefore using 0 seems correct in terms of behaving the same
> as native drivers do on those versions. I''m not sure I would want
to
> backport the addition of the extra padding in our drivers, the distros
> haven''t seen the need for example...
  Hmm, I thought that NET_IF_ALIGN mismatch between netfront and netback
occures a confusion of VNIF. But I might be imagining if it was used
correctly.

  Is it used on SLES9 guest ? I don''t have the environment.

Thanks,
- Tsunehisa Doi

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

On Fri, 2006-10-27 at 13:11 +0900, Doi.Tsunehisa@jp.fujitsu.com
wrote:
> Takanori (he is my co-worker) checked this patch, but it occures
> compile error in linux-xen. We are investigating it.
Thanks, I''ll reply to him in a moment.
> >>   BTW, I might find a issue about NET_IP_ALIGN in the compatible
shim.
> >> Currentry, its value is 0, but the value should be matched a value
of
> >> netback module. Thus, its value should be 2, I think.
> >> 
> >>   What do you think about the issue ?
> >
> > My thinking was that since those older kernels don''t define
NET_IP_ALIGN
> > and don''t hardcode the number 2 anywhere they don''t
expect any extra
> > alignment. Therefore using 0 seems correct in terms of behaving the
same
> > as native drivers do on those versions. I''m not sure I would
want to
> > backport the addition of the extra padding in our drivers, the distros
> > haven''t seen the need for example...
> 
> Hmm, I thought that NET_IF_ALIGN mismatch between netfront and netback
> occures a confusion of VNIF. But I might be imagining if it was used
> correctly.
I''d not heard about or seen that problem. Lets leave things as they are
and if a problem arises we''ll revisit it.
> Is it used on SLES9 guest ? I don''t have the environment.
Yes, I''m compile testing against SLES9sp3 (2.6.5 based) and RHEL4
update
4 (2.6.9 based) kernels. I don''t have an IA64 platform to do anything
more than that.

Ian.



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

Hi Ian,
>> How do you think of this patch?
> 
> In general we want to avoid adding compatibility bits to generic code
> and confine it to platform-compat.[ch] wherever possible. You have added
> code in xencomm.[ch] and hypercall.h which I think we can avoid.
> 
> I also try to avoid checking version numbers if I can, preferring to
> check for the presence of absence of specific definitions instead. This
> is useful when dealing with kernels with backported bits. Unfortunately
> it doesn''t help with the gfp_t typedef :-( but we''ll come
to that later.
> 
> I''ve attached my current patch including the ptrace fix from above
and
> the comments from below. Can you give it a go?
I''ll try it.

Thanks

-
Takanori Kasai


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

Hi Ian,

I confirmed this patch.
However, this patch has not been applied yet.

Do you think that this patch has another problem?
If this patch has no problem, could you apply this patch?

Thanks

--
Takanori Kasai


----- Original Message ----- 
From: "Kasai Takanori" <kasai.takanori@jp.fujitsu.com>
To: "Ian Campbell" <Ian.Campbell@xensource.com>
Cc: "xen-ia64-devel" <xen-ia64-devel@lists.xensource.com>
Sent: Saturday, October 28, 2006 3:30 PM
Subject: [Xen-ia64-devel] Re: [Xen-devel][PATCH][RESEND] PV drivers for 
HVMguests

> Hi Ian,
>
>> I''ve attached my current patch including the ptrace fix from
above and
>> the comments from below. Can you give it a go?
>
> I confirmed this patch. (cs:12004)
> I tested compiling it and simple test on RHEL4U2 and RHEL4U4.
>
> Thanks
>
> --
> Takanori Kasai
>
>
> As follows:
> ------------
> diff -r cf05aabe6e65 linux-2.6-xen-sparse/include/asm-ia64/hypercall.h
> --- a/linux-2.6-xen-sparse/include/asm-ia64/hypercall.h Wed Oct 25 15:29:00
> 2006 -0600
> +++ b/linux-2.6-xen-sparse/include/asm-ia64/hypercall.h Sat Oct 28 13:30:39
> 2006 +0900
> @@ -39,6 +39,10 @@
>
> #include <asm/xen/xcom_hcall.h>
> struct xencomm_handle;
> +
> +#ifdef HAVE_XEN_PLATFORM_COMPAT_H
> +#include <xen/platform-compat.h>
> +#endif
>
> /*
>  * Assembler stubs for hyper-calls.
> diff -r cf05aabe6e65 linux-2.6-xen-sparse/include/asm-ia64/xen/xencomm.h
> --- a/linux-2.6-xen-sparse/include/asm-ia64/xen/xencomm.h Wed Oct 25
15:29:00
> 2006 -0600
> +++ b/linux-2.6-xen-sparse/include/asm-ia64/xen/xencomm.h Sat Oct 28
13:42:40
> 2006 +0900
> @@ -20,6 +20,10 @@
> #define _LINUX_XENCOMM_H_
>
> #include <xen/interface/xencomm.h>
> +
> +#ifdef HAVE_XEN_PLATFORM_COMPAT_H
> +#include <xen/platform-compat.h>
> +#endif
>
> #define XENCOMM_MINI_ADDRS 3
> struct xencomm_mini {
> diff -r cf05aabe6e65 
> unmodified_drivers/linux-2.6/compat-include/asm-generic/pgtable-nopud.h
> ---
a/unmodified_drivers/linux-2.6/compat-include/asm-generic/pgtable-nopud.h
> Wed Oct 25 15:29:00 2006 -0600
> +++
b/unmodified_drivers/linux-2.6/compat-include/asm-generic/pgtable-nopud.h
> Sat Oct 28 12:50:07 2006 +0900
> @@ -9,6 +9,7 @@
> #define pud_offset(d, va)     d
> #define pud_none(pud)         0
> #define pud_present(pud)      1
> +#define pud_bad(pud)          0
> #define PTRS_PER_PUD          1
>
> #endif /* _PGTABLE_NOPUD_H */
> diff -r cf05aabe6e65 
> unmodified_drivers/linux-2.6/compat-include/xen/platform-compat.h
> --- a/unmodified_drivers/linux-2.6/compat-include/xen/platform-compat.h Wed
> Oct 25 15:29:00 2006 -0600
> +++ b/unmodified_drivers/linux-2.6/compat-include/xen/platform-compat.h Sat
> Oct 28 13:16:35 2006 +0900
> @@ -25,6 +25,21 @@
> #define NET_IP_ALIGN 0
> #endif
>
> +#if defined(_LINUX_ERR_H) && !defined(IS_ERR_VALUE)
> +#define IS_ERR_VALUE(x) unlikely((x) > (unsigned long)-1000L)
> +#endif
> +
> +#if defined(_ASM_IA64_PGTABLE_H) && !defined(_PGTABLE_NOPUD_H)
> +#include <asm-generic/pgtable-nopud.h>
> +#endif
> +
> +/* Some kernels have this typedef backported so we cannot reliably
> + * detect based on version number, hence we forcibly #define it.
> + */
> +#if defined(__LINUX_TYPES_H) || defined(__LINUX_GFP_H)
> +#define gfp_t unsigned
> +#endif
> +
> #if defined(_LINUX_FS_H) && LINUX_VERSION_CODE <
KERNEL_VERSION(2,6,9)
> #define nonseekable_open(inode, filp) /* Nothing to do */
> #endif
>
>
>
> _______________________________________________
> Xen-ia64-devel mailing list
> Xen-ia64-devel@lists.xensource.com
> http://lists.xensource.com/xen-ia64-devel
> 


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

On Thu, 2006-11-02 at 08:55 +0900, Kasai Takanori wrote:
> Hi Ian,
> 
> I confirmed this patch.
> However, this patch has not been applied yet.
> 
> Do you think that this patch has another problem?
> If this patch has no problem, could you apply this patch?
Sorry, I simply forgot. I''ll get to it today.

Ian.



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