[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Il 28/11/2013 11:03, Fabio Fantoni ha scritto:
Il 27/11/2013 19:21, Anthony PERARD ha scritto:

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.


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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.