Re: [Xen-devel] [PATCH RFC v1 40/74] xen/x86: report domain id on cpuid

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 08/01/18 11:11, Jan Beulich wrote:
>>>> On 08.01.18 at 11:34, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 08/01/18 10:27, Jan Beulich wrote:
>>>>>> On 04.01.18 at 14:05, <wei.liu2@xxxxxxxxxx> wrote:
>>>> From: Roger Pau Monne <roger.pau@xxxxxxxxxx>
>>>>
>>>> Use the ebx register of the hypervisor leaf 1. The eax register on
>>>> this leaf is already used to report the Xen major and minor versions.
>>> The rationale for doing this is missing. Iirc in past discussions the
>>> opinion was voiced (more than once, and iirc by Andrew any maybe
>>> others) that a domain in general shouldn't be told about its domain
>>> ID. Otherwise I also can't see why we don't have a hypercall for
>>> this, and e.g. XTF needs to go through hoops to figure it out. Are
>>> those arguments (which I don't recall) not applicable anymore?
>>>
>>> In the Amazon shim patches thread handing out the domain ID by
>>> command line option was suggested as an alternative, which then
>>> wouldn't affect other (non-shim) domains, or the client of the shim.
>> A guests domid is unconditionally always available in xenstore, and is a
>> necessary part of any PV communication.
>>
>> Like it or not, domid is part of the guests view of the Xen ABI. 
>> Therefore, making it easily accessible is the best course of action
>> (especially as pv-shim deliberately doesn't interpose on the xenstore ring).
> All understood, yet you don't address the question on the
> backgrounds of the change of your opinion here. Or am I
> misremembering that earlier on you were against exposing
> the domain ID?

In the past, I was concerned about how a guest can brute force its own
domid via leaky error conditions in some hypercalls.  I still think
these should be fixed.

Ideally, a guest wouldn't know its own domid, but we're 15 years too
late on that line of thought...

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel