[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH V3 01/19] x86: Create per-domain mapping of guest_root_pt
On 14/05/2024 09:03, Jan Beulich wrote: > On 13.05.2024 17:27, Roger Pau Monné wrote: >> On Mon, May 13, 2024 at 11:10:59AM +0000, Elias El Yandouzi wrote: >>> @@ -317,6 +317,14 @@ extern unsigned long xen_phys_start; >>> #define ARG_XLAT_START(v) \ >>> (ARG_XLAT_VIRT_START + ((v)->vcpu_id << ARG_XLAT_VA_SHIFT)) >>> >>> +/* pv_root_pt mapping area. The fourth per-domain-mapping sub-area */ >>> +#define PV_ROOT_PT_MAPPING_VIRT_START PERDOMAIN_VIRT_SLOT(3) >>> +#define PV_ROOT_PT_MAPPING_ENTRIES MAX_VIRT_CPUS >>> + >>> +/* The address of a particular VCPU's PV_ROOT_PT */ >>> +#define PV_ROOT_PT_MAPPING_VCPU_VIRT_START(v) \ >>> + (PV_ROOT_PT_MAPPING_VIRT_START + ((v)->vcpu_id * PAGE_SIZE)) >> >> I know we are not there yet, but I wonder if we need to start having >> some non-shared per-cpu mapping area in the page-tables. Right now >> this is shared between all the vCPUs, as it's per-domain space >> (instead of per-vCPU). > > In turn requiring per-vCPU page tables, posing a problem when a guest > uses the same page tables for multiple vCPU-s. > > Jan > True. Having separate page tables per CPU is an unavoidable end goal for a hypervisor claiming to hold no secrets, however. Otherwise any CPU can still speculatively read the stacks of other CPUs and take well-timed glances over mappings set transiently by any other CPU. Cheers, Alejandro
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |