qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3] Hvmloader: Modify ACPI to only supply _EJ0 m


From: Fabio Fantoni
Subject: Re: [Qemu-devel] [PATCH v3] Hvmloader: Modify ACPI to only supply _EJ0 methods for PCIslots that support hotplug by runtime patching
Date: Fri, 09 May 2014 16:14:27 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

Il 08/05/2014 13:23, Gonglei (Arei) ha scritto:
Hi,

-----Original Message-----
From: Fabio Fantoni [mailto:address@hidden
Sent: Thursday, May 08, 2014 4:17 PM
To: Gonglei (Arei); address@hidden; address@hidden
Cc: address@hidden; address@hidden;
address@hidden; address@hidden; Huangweidong
(C); Hanweidong (Randy); Gaowei (UVP); Michael S. Tsirkin
Subject: Re: [PATCH v3] Hvmloader: Modify ACPI to only supply _EJ0 methods
for PCIslots that support hotplug by runtime patching

Il 08/05/2014 06:12, Gonglei (Arei) ha scritto:
Hi,

In Xen platform, after using upstream qemu, the all of pci devices will
show
hotplug in the windows guest. In this situation, the windows guest may
occur
blue screen when VM' user click the icon of VGA card for trying unplug
VGA
card.
However, we don't hope VM's user can do such dangerous operation, and
showing
all pci devices inside the guest OS is unfriendly.

This is done by runtime patching:
     - Rename _EJ0 methods for PCI slots in DSDT to EJ0_:note that this
has
the
       same checksum, but is ignored by OSPM.
     - At compile time, look for these methods in ASL source,find the
matching
AML,
       and store the offsets of these methods in a table named
aml_ej0_data.
     - At run time, go over aml_ej0_data, check which slots not support
hotplug
and
       patch the ACPI table, replacing _EJ0 with EJ0_.

Signed-off-by: Gaowei <address@hidden>
Signed-off-by: Gonglei <address@hidden>
Tested-by: Fabio Fantoni <address@hidden>

Thanks for this very useful patch that avoid that unaware users or as
mistake make windows domUs unusable.

Thanks.

I tried to quickly look at the patch to understand how to add some
optional components, for example on my case the pv drivers, the audio
card and the spice guest tools (see attachment) but I don't understand
how to do it.
Can someone give me some advices about it please?

Maybe you can hard code at libxl__build_device_model_args_new()
in tools/libxl/libxl_dm.c


Best regards,
-Gonglei

I believe I not understand what you mean.
About adding these components I already do this:
- gplpv: http://wiki.xen.org/wiki/Xen_Windows_GplPv
http://www.ejbdigital.com.au/gplpv
- spice:
http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html#spice_graphics_suppo
rt
http://www.spice-space.org/download/binaries/spice-guest-tools/
- audio: add soundhw="hda" in domU's xl cfg file

This patch disables hotplug capabilities from essential pci devices.

No, if pci devices do not support hotplug, which class's no_hotplug property 
will be
set to 1, then the pci device will not show in guest os, opposite will be 
shown, such
as your pv drivers and Intel hda card.

Please see intel_hda_class_init_common() and xen_platform_class_init() 
functions.
As a comparison, you can see vga devices' class init function 
cirrus_vga_class_init()
has below code:

k->no_hotplug = 1;

If I understand what you mean wrong, please forgive me.

I saw in qemu code that intel_hda_class_init_common() and xen_platform_class_init() functions (and probably also virtio serial one) not have k->no_hotplug but in windows domUs show them in hotplug devices list, also with this your patch applied. (see part of screenshoot in attachment)
I not understand how to remove also them from windows hotplug devices list.

Thanks for any reply and sorry for my bad english.


What I mean if there is a way to prevent some other components being
part of the above list of hotplug devices.

Thanks for any reply and sorry for my bad english.
Best regards,
-Gonglei

Attachment: optional-devices.jpg
Description: JPEG image


reply via email to

[Prev in Thread] Current Thread [Next in Thread]