Re: [RFC PATCH 16/27] KVM: arm64: Prepare Hyp memory protection

2020-12-08 Thread Will Deacon
On Mon, Dec 07, 2020 at 02:11:20PM +, Quentin Perret wrote: > On Monday 07 Dec 2020 at 13:40:52 (+), Will Deacon wrote: > > Why not use the RESERVEDMEM_OF_DECLARE() interface for the hypervisor > > memory? That way, the hypervisor memory can either be statically partitioned > > as a

Re: [RFC PATCH 16/27] KVM: arm64: Prepare Hyp memory protection

2020-12-07 Thread Quentin Perret
On Monday 07 Dec 2020 at 13:54:48 (+), Marc Zyngier wrote: > None. Whichever name you pick, someone will ask you to change it. > Just call it Bob. :-) > What I really *don't* want is see a blanket rename of existing symbols > or concepts. Understood. I'll go with pkvm_create_mappings() and

Re: [RFC PATCH 16/27] KVM: arm64: Prepare Hyp memory protection

2020-12-07 Thread Quentin Perret
On Monday 07 Dec 2020 at 13:40:52 (+), Will Deacon wrote: > Why not use the RESERVEDMEM_OF_DECLARE() interface for the hypervisor > memory? That way, the hypervisor memory can either be statically partitioned > as a carveout or allocated dynamically for us -- we wouldn't need to care. Yup, I

Re: [RFC PATCH 16/27] KVM: arm64: Prepare Hyp memory protection

2020-12-07 Thread Quentin Perret
On Monday 07 Dec 2020 at 11:16:05 (+), Fuad Tabba wrote: > On Fri, Dec 4, 2020 at 6:01 PM Quentin Perret wrote: > > > > On Thursday 03 Dec 2020 at 12:57:33 (+), Fuad Tabba wrote: > > > > > > +int hyp_create_idmap(void); > > > > +int hyp_map_vectors(void); > > > > +int

Re: [RFC PATCH 16/27] KVM: arm64: Prepare Hyp memory protection

2020-12-07 Thread Fuad Tabba
On Fri, Dec 4, 2020 at 6:01 PM Quentin Perret wrote: > > On Thursday 03 Dec 2020 at 12:57:33 (+), Fuad Tabba wrote: > > > > +int hyp_create_idmap(void); > > > +int hyp_map_vectors(void); > > > +int hyp_back_vmemmap(phys_addr_t phys, unsigned long size, phys_addr_t > > > back); > > > +int

Re: [RFC PATCH 16/27] KVM: arm64: Prepare Hyp memory protection

2020-12-07 Thread Fuad Tabba
On Mon, Dec 7, 2020 at 11:05 AM Mark Rutland wrote: > > On Mon, Dec 07, 2020 at 10:20:03AM +, Will Deacon wrote: > > On Fri, Dec 04, 2020 at 06:01:52PM +, Quentin Perret wrote: > > > On Thursday 03 Dec 2020 at 12:57:33 (+), Fuad Tabba wrote: > > > > > > > >

Re: [RFC PATCH 16/27] KVM: arm64: Prepare Hyp memory protection

2020-12-07 Thread Marc Zyngier
On 2020-12-07 11:58, Quentin Perret wrote: On Monday 07 Dec 2020 at 11:16:05 (+), Fuad Tabba wrote: On Fri, Dec 4, 2020 at 6:01 PM Quentin Perret wrote: > > On Thursday 03 Dec 2020 at 12:57:33 (+), Fuad Tabba wrote: > > > > +int hyp_create_idmap(void); > > > +int

Re: [RFC PATCH 16/27] KVM: arm64: Prepare Hyp memory protection

2020-12-07 Thread Will Deacon
Hi Quentin, On Tue, Nov 17, 2020 at 06:15:56PM +, Quentin Perret wrote: > When memory protection is enabled, the Hyp code needs the ability to > create and manage its own page-table. To do so, introduce a new set of > hypercalls to initialize Hyp memory protection. > > During the init hcall,

Re: [RFC PATCH 16/27] KVM: arm64: Prepare Hyp memory protection

2020-12-07 Thread Will Deacon
On Mon, Dec 07, 2020 at 11:05:45AM +, Mark Rutland wrote: > On Mon, Dec 07, 2020 at 10:20:03AM +, Will Deacon wrote: > > On Fri, Dec 04, 2020 at 06:01:52PM +, Quentin Perret wrote: > > > On Thursday 03 Dec 2020 at 12:57:33 (+), Fuad Tabba wrote: > > > > > > > >

Re: [RFC PATCH 16/27] KVM: arm64: Prepare Hyp memory protection

2020-12-07 Thread Mark Rutland
On Mon, Dec 07, 2020 at 10:20:03AM +, Will Deacon wrote: > On Fri, Dec 04, 2020 at 06:01:52PM +, Quentin Perret wrote: > > On Thursday 03 Dec 2020 at 12:57:33 (+), Fuad Tabba wrote: > > > > > > +SYM_FUNC_START(__kvm_init_switch_pgd) > > > > + /* Turn the MMU off */ > > > > +

Re: [RFC PATCH 16/27] KVM: arm64: Prepare Hyp memory protection

2020-12-07 Thread Will Deacon
On Fri, Dec 04, 2020 at 06:01:52PM +, Quentin Perret wrote: > On Thursday 03 Dec 2020 at 12:57:33 (+), Fuad Tabba wrote: > > > > +int hyp_create_idmap(void); > > > +int hyp_map_vectors(void); > > > +int hyp_back_vmemmap(phys_addr_t phys, unsigned long size, phys_addr_t > > > back); > > >

Re: [RFC PATCH 16/27] KVM: arm64: Prepare Hyp memory protection

2020-12-04 Thread Quentin Perret
On Thursday 03 Dec 2020 at 12:57:33 (+), Fuad Tabba wrote: > > +int hyp_create_idmap(void); > > +int hyp_map_vectors(void); > > +int hyp_back_vmemmap(phys_addr_t phys, unsigned long size, phys_addr_t > > back); > > +int hyp_cpu_set_vector(enum arm64_hyp_spectre_vector slot); > > +int

Re: [RFC PATCH 16/27] KVM: arm64: Prepare Hyp memory protection

2020-12-03 Thread Fuad Tabba
Hi Quentin, On Tue, Nov 17, 2020 at 6:17 PM 'Quentin Perret' via kernel-team wrote: > > When memory protection is enabled, the Hyp code needs the ability to > create and manage its own page-table. To do so, introduce a new set of > hypercalls to initialize Hyp memory protection. > > During the

[RFC PATCH 16/27] KVM: arm64: Prepare Hyp memory protection

2020-11-17 Thread Quentin Perret
When memory protection is enabled, the Hyp code needs the ability to create and manage its own page-table. To do so, introduce a new set of hypercalls to initialize Hyp memory protection. During the init hcall, the hypervisor runs with the host-provided page-table and uses the trivial early page