RE: [Xen-devel] Debian kernel doesn't support DomU bit width != Dom0 bit width for PV drivers?

["Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>]

Could be totally unrelated, but (despite the name of the patch)
this might be relevant:

http://lists.xensource.com/archives/html/xen-devel/2008-01/msg00509.html

Mixed bit-width-mode dom0 vs domU probably has some lurking bugs.
Oracle has pounded on 64-bit domU on 32-bit dom0 quite a bit,
but not vice-versa.

Note that a 64-bit dom0 isn't required to run 64-bit guests,
just a 64-bit Xen.  As a result, I don't know if any commercial
products run a 64-bit dom0, so the 32-on-64 bugs probably haven't
been shaken out.

Dan

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of 
> James Harper
> Sent: Friday, February 01, 2008 3:25 PM
> To: xen-devel
> Subject: [Xen-devel] Debian kernel doesn't support DomU bit width !=
> Dom0 bit width for PV drivers?
> 
> 
> In trying to figure out why my Xen Windows PV drivers don't work
> properly when the frontend and backend are different bit 
> width modes (eg
> 32, 64), I figured out that the same is true for Linux 
> domains. I tested
> a 32 bit DomU with a 64 bit Dom0, and get a crash almost as 
> soon as the
> blkfront driver is started, and a "(XEN) grant_table.c:264:d0 
> Bad flags
> (0) or dom (0). (expected dom 0)" message logged in 'xm dmesg'.
> 
> My suspicion then is that the Debian kernel's blkback driver 
> doesn't pay
> attention to the 'protocol' set by the frontend, even though blkfront
> driver included in the Debian kernel does actually set it.
> 
> Can anyone confirm this behaviour?
> 
> Thanks
> 
> James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>


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