RE: [Xen-devel] Crash during boot in Debian lenny default dom0 kernel (2.6.26-2-xen-686)

["Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>]

Hmm, this issue is caused because of changeset 18323, which extend the 
physdev_map_pirq strucutre. IIRC, this is mainly for SR-IOV support, that Xen 
can't get the MMIO BAR from the virtual device.

However, dig into futher, I suspect if we need to change the definition of 
'struct physdev_op'. Currently there is no maxium length limit, should it have 
something like the "pad" in struct xen_platform_op?
One possibility is, if one new type physdev operation added, which extend the 
length of struct physdev_op, it may cause issue (like copy_from_guest in 
do_physdev_op failed randomly). 
But I have no idea of how to add the padd without breaking compatibility.

--jyh

@@ -136,10 +136,13 @@ struct physdev_map_pirq {
     /* IN or OUT */
     int pirq;
     /* IN */
-    struct {
-        int bus, devfn, entry_nr;
-       int msi;  /* 0 - MSIX    1 - MSI */
-    } msi_info;
+    int bus;
+    /* IN */
+    int devfn;
+    /* IN */
+    int entry_nr;
+    /* IN */
+    uint64_t table_base;


>-----Original Message-----
>From: dunlapg@xxxxxxxxx [mailto:dunlapg@xxxxxxxxx] On Behalf Of George
>Dunlap
>Sent: Thursday, February 25, 2010 8:14 PM
>To: Jan Beulich
>Cc: Jiang, Yunhong; Sander Eikelenboom; xen-devel@xxxxxxxxxxxxxxxxxxx; Jeremy
>Fitzhardinge
>Subject: Re: [Xen-devel] Crash during boot in Debian lenny default dom0 kernel
>(2.6.26-2-xen-686)
>
>(Jeremy: Discussing the default Lenny dom0 package, 2.6.26-2-xen--686
>crashing during boot if MSIs are available.)
>
>Sure enough, the structure it's using looks like this:
>
>struct physdev_map_pirq {
>    domid_t domid;
>    /* IN */
>    int type;
>    /* IN */
>    int index;
>    /* IN or OUT */
>    int pirq;
>    /* IN */
>    struct {
>        int bus, devfn, entry_nr;
>        int msi;  /* 0 - MSIX    1 - MSI */
>    } msi_info;
>};
>
>The code in question came from a patch called
>suse-20080808143035.patch; reading the numbers as the timestamp "2008
>August 8" would seem to match up with the 3.3 dev lifecycle.
>
>Any suggestions for a simple fix I can try to push upstream?
>
> -George
>
>On Thu, Feb 25, 2010 at 11:46 AM, George Dunlap
><George.Dunlap@xxxxxxxxxxxxx> wrote:
>> I'm looking at the debian source package for this kernel to see if I
>> can sort out where it got the header from.
>>
>> Given that this is already in a major distribution, is there any way
>> we can fail gracefully if someone's running this kernel?  I'm not
>> familiar enough with the MSI to know if this is possible, or what a
>> good set of "sanity checks" would be for failing the hypercall.
>>
>>  -George
>>
>> On Thu, Feb 25, 2010 at 10:56 AM, Jan Beulich <JBeulich@xxxxxxxxxx> wrote:
>>>>>> George Dunlap <George.Dunlap@xxxxxxxxxxxxx> 25.02.10 11:48 >>>
>>>>Is it possible that there's actually a bug in the compat code, and
>>>>that table_base actually *was* set to (uint32_t)1?  If a reasonable
>>>>number for table_base is "1", giving it 64 bits in the structure would
>>>>seem a bit like overkill...
>>>
>>> "1" definitely is not a reasonable value here. And it's also not the
>>> compat code I'm sure - it is the kernel using a bad structure definition.
>>>
>>> Jan
>>>
>>>
>>> _______________________________________________
>>> 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