Re: [Xen-devel] [PATCH v2] x86/hvm: do not register hpet mmio during s3 cycle

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.11.17 at 15:42, <julien.grall@xxxxxxxxxx> wrote:
> Hi,
> 
> On 09/11/17 08:55, Jan Beulich wrote:
>>>>> On 08.11.17 at 20:46, <chanudete@xxxxxxxxxxxx> wrote:
>>> Do it once at domain creation (hpet_init).
>>>
>>> Sleep -> Resume cycles will end up crashing an HVM guest with hpet as
>>> the sequence during resume takes the path:
>>> -> hvm_s3_suspend
>>>    -> hpet_reset
>>>      -> hpet_deinit
>>>      -> hpet_init
>>>        -> register_mmio_handler
>>>          -> hvm_next_io_handler
>>>
>>> register_mmio_handler will use a new io handler each time, until
>>> eventually it reaches NR_IO_HANDLERS, then hvm_next_io_handler calls
>>> domain_crash.
>>>
>>> Signed-off-by: Eric Chanudet <chanudete@xxxxxxxxxxxx>
>>>
>>> ---
>>> v2:
>>>    * make hpet_reinit static inline (one call site in this file)
>> 
>> Perhaps my prior reply was ambiguous: By "inlining" I meant
>> literally inlining it (i.e. dropping the standalone function
>> altogether). Static functions outside of header files should not
>> normally be marked "inline" explicitly - it should be the compiler
>> to make that decision.
>> 
>> As doing the adjustment it relatively simple, I wouldn't mind
>> doing so while committing, saving another round trip. With
>> that adjustment (or at the very least with the "inline" dropped)
>> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> What would be the risk to get this patch in Xen 4.10?

Close to none, I would say. Of course, if there really was
something wrong with the code restructuring to fix the bug,
basically all HVM guests would be hosed HPET-wise.

Jan


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