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

[Fabio Fantoni <fabio.fantoni@xxxxxxx>]

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