RE: [Xen-devel] [PATCH] Fix hvm vcpu hotplug bug

["Liu, Jinsong" <jinsong.liu@xxxxxxxxx>]

Ian Jackson wrote:
> Liu, Jinsong writes ("RE: [Xen-devel] [PATCH] Fix hvm vcpu hotplug
> bug"): 
>> Ian Jackson wrote:
>>> Liu, Jinsong writes ("RE: [Xen-devel] [PATCH] Fix hvm vcpu hotplug
>>> bug"): 
>>>> [linux/drivers/acpi/acpica/ will:]
>>>> 1). clear pge_en x by writing '0' to the bit;
>>>> 2). asynchronic call control method;
>>>> 3). clear gpe_sts x by writing '1' to the bit;
>>>> 4). re-enable gpe_en x by writing '1' to the bit;
>>> 
>>> So the code in qemu should never clear gpe_sts itself.
>> 
>> No, that's just what qemu should do, to simulate hardware behavior.
> 
> Obviously I still haven't understood.  If the guest kernel driver is
> supposed to clear this bit as you seem to say above, then it should
> not be cleared automatically by qemu-dm as part of the hotplug
> notification.

Of course hotplug notification will not clear gpe_sts.
At qemu side, 'hotplug notification' and 'clear gpe_sts' are asynchronic:
1) qemu: hotplug notification trigger sci, 
2) guest kernel: 
        a). clear pge_en x by writing '0' to the bit;
        b). asynchronically clear gpe_sts x by writing '1' to the bit;
        c). re-enable gpe_en x by writing '1' to the bit;
3) qemu: gpe_en_write/gpe_sts_write will simulate the hardware action to set or 
clear gpe_en/gpe_sts.

What I mean is, currently at qmeu side, it need add the logic of 'multi gpe --> 
OR --> sci' logic.
(i.e, at current qemu hw/piix4acpi.c, gpe_sts_write and gpe_en_write cannot 
handle multi gpe).
Only after add the logic, it could be clean to handle 'vcpu hotplug' at qmeu.

Thanks,
Jinsong

> 
> Obviously the register ought to be emulated by qemu and the bit ought
> to be cleared in qemu when the kernel driver writes an inactive value
> to it.
> 
> None of this seems to be implemented in qemu right now AFAICT ?
> 
> Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel