[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 7/7] x86/viridian: implement the crash MSRs
> -----Original Message----- > From: Jan Beulich [mailto:JBeulich@xxxxxxxx] > Sent: 20 March 2017 13:29 > To: Paul Durrant <Paul.Durrant@xxxxxxxxxx> > Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; Ian Jackson > <Ian.Jackson@xxxxxxxxxx>; Wei Liu <wei.liu2@xxxxxxxxxx>; xen- > devel@xxxxxxxxxxxxxxxxxxxx > Subject: RE: [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. > Ok. Given it's not very much data, I'll make them per-vcpu just in case. > >> 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. > I think that's probably an acceptable risk. I won't add them to the migration stream for the moment. Paul > Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |