On 30/10/2019 12:02, Jan Beulich wrote: > On 30.10.2019 12:43, Andrew Cooper wrote: >> On 30/10/2019 10:39, Jan Beulich wrote: >>> To fulfill the "protected" in its name, don't let the real hardware >>> values "shine through". Report a control register value expressing this. >>> >>> Signed-off-by: Jan Beulich <jbeul...@suse.com> >>> --- >>> TBD: Do we want to permit Dom0 access? >> I would recommend reordering the two patches and putting this one first >> (along with the enumeration details, along with a pair of feature >> strings in xen-cpuid). This patch at least wants backporting. > Well, the reason for this ordering is because this way Dom0 > doesn't transiently lose all access.
Nothing pre-existing can be used reliably by dom0 because of the raz/write-discard behaviour. I wouldn't complicate patch ordering because of this. > > As to xen-cpuid - I admit I simply forgot to update it, largely > due to there not being any CPUID bit on the Intel side. That part > would obviously live in whichever patch we elect to be first. > >> This would be far more simple if we don't permit dom0 access. Yes, it >> shares platform responsibility with Xen, but it also can't do anything >> more with the value than Xen can, which is to simply print it out for #MCEs. > Okay, then let's not expose it. I'll drop the TBD. I'll re-review with dom0 access in mind, but start a new thread. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
