[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2] x86/hvm: do not register hpet mmio during s3 cycle
Hi Jan, On 11/09/2017 02:45 PM, Jan Beulich wrote: 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. On that basis: Release-acked-by: Julien Grall <julien.grall@xxxxxxxxxx> Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |