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
|
Home