[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.