> On 8 Nov 2019, at 17:35, Christophe de Dinechin <christophe.de.dinechin@xxxxxxxxx> wrote: > > > >> On 7 Nov 2019, at 16:02, Liran Alon <liran.alon@xxxxxxxxxx> wrote: >> >> >> >>> On 7 Nov 2019, at 16:00, Christophe de Dinechin <christophe.de.dinechin@xxxxxxxxx> wrote: >>> >> >>> >>> I share that concern about the naming, although I do see some >>> value in exposing the cpu_smt_possible() result. I think it’s easier >>> to state that something does not work than to state something does >>> work. >>> >>> Also, with respect to mitigation, we may want to split the two cases >>> that Paolo outlined, i.e. have KVM_HINTS_REALTIME, >>> KVM_HINTS_CORES_CROSSTALK and >>> KVM_HINTS_CORES_LEAKING, >>> where CORES_CROSSTALKS indicates there may be some >>> cross-talk between what the guest thinks are isolated cores, >>> and CORES_LEAKING indicates that cores may leak data >>> to some other guest. >>> >>> The problem with my approach is that it is shouting “don’t trust me” >>> a bit too loudly. >> >> I don’t see a value in exposing CORES_LEAKING to guest. As guest have nothing to do with it. > > The guest could display / expose the information to guest sysadmins > and admin tools (e.g. through /proc). > > While the kernel cannot mitigate, a higher-level product could for example > have a policy about which workloads can be deployed on a system which > may leak data to other VMs. > > Christophe Honestly, I don’t think any sane cloud provider will schedule vCPUs of different guests on same physical CPU core and report this to guest. Therefore, I think this is only relevant for use-cases where the guest owner is also the host/hypervisor owner. And therefore, doesn’t need this information exposed in a CPUID bit. I see your point regarding how in theory it could be used, but I think we should wait and see if such use-case exists before defining this interface. -Liran
