Re: [Xen-devel] [PATCH v11 1/9] x86: add generic MSR access hypercall

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.06.14 at 09:29, <dongxiao.xu@xxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Platform ops are for use by Dom0, yes, but note the explicit omission
>> of "kernel" in my reply. The fact that libxc currently doesn't use any
>> doesn't mean it mustn't do so. The only question here that matter is
>> what audience we see for the new functionality: If this is to be a
>> purely tools interface, then a sysctl is fine. If the kernel is intended to
>> also be able to use it (as I suggested), something other than a sysctl
>> needs to be used (and I was merely _hinting_ at platform-op).
> 
> I got such concept in the file descriptor, and that's why I was thinking of 
> platform-op is for dom0-kernel only...
> Looking through all the current hypercalls, sysctl and platform-op are the 
> most appropriate ones.
> 
> According to your word, if that's is not the limitation for Dom0 kernel 
> only, I am okay to change it to platform-op wise.

The most obvious example where functionality shouldn't be limited to
the kernel would be the microcode update operation: Just like for
kexec there's really nothing requiring the user mode tool to use the
kernel as a relay for data it wants the hypervisor to process - it
could (and imo should) talk to the hypervisor directly, thus at once
ending the discussion about the need for a runtime kernel driver in
the pv-ops case under Xen.

> BTW, do we need to modify the file header for platform_hypercall.c/h?
> 
> /******************************************************************************
>  * platform_hypercall.c
>  *
>  * Hardware platform operations. Intended for use by domain-0 kernel.

We might, but I don't view this as strictly necessary. But if you do,
the public header would be even more relevant to adjust.

>> > Do you mean the following case?
>> >
>> > Op1: CPU0, write MSR 0x100. Flag: 1 (indicating paring)
>> > Op2: CPU1, read MSR 0x200. Flag: 0.
>> > Op3: CPU0, read MSR 0x101. Flag: 1 (paring the above op1)
>> 
>> No - CPU changes alway imply preemption between individual
>> sub-ops.
> 
> Okay. Let's change the example a bit.
> 
> Op1: CPU0, write MSR 0x100.
> Op2: CPU0, read MSR 0x101.
> Op3: CPU1, read MSR 0x200.
> 
> Can we just follow the above example, if the two operations are "continuous" 
> towards a target CPU, then we will pack them together via a single IPI?
> Or do we really need the flag to indicate no-preemption there?

Without explicit request for no preemption, a preemption check
should imo be put between any two sub-ops. And, as said before,
we should be rather rigid when it comes to noticing abuse of the
flag (i.e. a first implementation could not permit the flag to be set
in consecutive array elements).

Jan


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