Re: [Xen-devel] [PATCH v2] Handle xen_platform_pci=0 case

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Thursday, November 28, 2013, 5:07:50 PM, you wrote:

> Il 28/11/2013 11:03, Fabio Fantoni ha scritto:
>> Il 27/11/2013 19:21, Anthony PERARD ha scritto:
>>> Hi,
>>>
>>> Here is a little patch that attempt to fix the issue regarding
>>> xen_platform_pci=0 not been handled.
>>>
>>> There is one patch left from the previous version. The patch that was 
>>> adding
>>> qemu_machine_override have been removed as it is unnecessary. If 
>>> someone wants
>>> to change the -machine, it can always add it to 
>>> device_model_args_hvm, as QEMU
>>> appear to use the last one.
>>>
>>> Regards,
>>>
>>> Anthony PERARD (1):
>>>    libxl: Handle xen_platform_pci=0 case with qemu-xen.
>>>
>>>   tools/libxl/libxl_dm.c | 12 ++++++++++--
>>>   1 file changed, 10 insertions(+), 2 deletions(-)
>>>
>>
>> The patch seems good and is working, the problem of kernel panic on 
>> hvm linux domU with xen_platform_pci=0 seems problem of xen modules 
>> kernel side.
>> I think that xen modules of linux kernel need to be fixed and/or 
>> improved (with backports to lts kernel versions).
>> Probably xen modules can cause an issue also on other case, for 
>> example this kernel problem with spice vdagent where I not found 
>> solution for now:
>> http://lists.freedesktop.org/archives/spice-devel/2013-October/015185.html 
>>
>>
>> I also tried xen_platform_pci=0 on windows 7 with gplpv installed and 
>> gave blu screen, this should be windows problem, is know that is not 
>> adactive and give blu screen also on phisical hardware when mainly 
>> components change.
>> Without gplpv windows 7 boots also with xen_platform_pci=0.
>> Probably I also found that with xen_platform_pci=0 seems that solve 
>> qxl "refresh problem" on windows.
>> I'll try to further understand what xen cause conflicts or unforeseen 
>> cases.

perhaps the gplpv drivers suffer from the same logic als the linux kernel
does (without konrad's patch) ?

> I did another tests and I can confirm that the main big problem with qxl 
> on windows domUs without gplpv and with xen_platform_pci=0 seems missed!
> Time ago I tested only removing gplpv but the problem remain.

> The only component missed in this case with qxl working is -device 
> xen-platform, right?
> I tried to found possible cause of the qxl problem and I found this doc 
> patch:
> http://lists.xen.org/archives/html/xen-devel/2013-11/msg01897.html
> I saw this part:
>> +    Also the size parameter (default 0x400000) can be used to specify the
>> +    size of the single MMIO BAR that the device exposes. This area may be
>> +    used by drivers for mapping grant tables, etc.
> can be the cause of possible conflict with qxl?
> If not what other things can be different in the case of xen_platform_pci=0?

> Thanks for any reply and sorry for my bad english.





_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel