[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 7/7] x86/viridian: implement the crash MSRs
>>> On 20.03.17 at 13:48, <Paul.Durrant@xxxxxxxxxx> wrote: >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx] >> Sent: 20 March 2017 12:38 >> >>> On 17.03.17 at 10:57, <paul.durrant@xxxxxxxxxx> wrote: >> > --- a/xen/include/asm-x86/hvm/viridian.h >> > +++ b/xen/include/asm-x86/hvm/viridian.h >> > @@ -96,6 +96,7 @@ struct viridian_domain >> > union viridian_hypercall_gpa hypercall_gpa; >> > struct viridian_time_ref_count time_ref_count; >> > union viridian_reference_tsc reference_tsc; >> > + uint64_t crash_param[5]; >> >> Are these really per-domain values (normally MSRs are per-vCPU)? > > I don't think the usage described in section 4.3 really warrants per-vCPU. > I've not looked at the exact sequence of events but I'm fairly sure the MSRs > are written by the Windows crash kernel, which is single threaded. Well, what I'm wondering about here is whether it wouldn't be possible (and reasonable) to have two vCPU-s crashing at almost the same time write independent values. They might then even sync with one another to settle on who of them should do the final MSR write. But if they're indeed only (meant to be) written by the (single threaded) crash kernel (which I find strange), then of course these are fine per-domain. >> And don't they need migrating? > > I don't think so, given that they are only written just prior to the domain > dying anyway. Well, that leaves the risk of the host admin to decide moving the domain the very moment it is doing its final crash processing. Which may of course be an acceptable risk. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |