Re: [PATCH] x86/traps: Rework #PF[Rsvd] bit handling

2020-05-20 Thread Andrew Cooper
On 20/05/2020 08:48, Jan Beulich wrote: > On 19.05.2020 20:00, Andrew Cooper wrote: >> On 19/05/2020 17:09, Jan Beulich wrote: >>> In any event there would be 12 bits to reclaim from the up >>> pointer - it being a physical address, there'll not be more >>> than 52 significant bits. >> Right, but f

Re: [PATCH] x86/traps: Rework #PF[Rsvd] bit handling

2020-05-20 Thread Jan Beulich
On 19.05.2020 20:00, Andrew Cooper wrote: > On 19/05/2020 17:09, Jan Beulich wrote: >> In any event there would be 12 bits to reclaim from the up >> pointer - it being a physical address, there'll not be more >> than 52 significant bits. > > Right, but for L1TF safety, the address bits in the PTE

Re: [PATCH] x86/traps: Rework #PF[Rsvd] bit handling

2020-05-20 Thread Tim Deegan
At 18:09 +0200 on 19 May (1589911795), Jan Beulich wrote: > static inline int sh_type_has_up_pointer(struct domain *d, unsigned int t) > { > /* Multi-page shadows don't have up-pointers */ > if ( t == SH_type_l1_32_shadow > || t == SH_type_fl1_32_shadow > || t == SH_type_l

Re: [PATCH] x86/traps: Rework #PF[Rsvd] bit handling

2020-05-19 Thread Andrew Cooper
On 19/05/2020 17:09, Jan Beulich wrote: > On 19.05.2020 17:33, Andrew Cooper wrote: >> On 19/05/2020 15:48, Jan Beulich wrote: >>> On 19.05.2020 16:11, Andrew Cooper wrote: Given that shadow frames are limited to 44 bits anyway (and not yet levelled safely in the migration stream), my sug

Re: [PATCH] x86/traps: Rework #PF[Rsvd] bit handling

2020-05-19 Thread Jan Beulich
On 19.05.2020 17:33, Andrew Cooper wrote: > On 19/05/2020 15:48, Jan Beulich wrote: >> On 19.05.2020 16:11, Andrew Cooper wrote: >>> Given that shadow frames are limited to 44 bits anyway (and not yet >>> levelled safely in the migration stream), my suggestion for fixing this >>> was just to use on

Re: [PATCH] x86/traps: Rework #PF[Rsvd] bit handling

2020-05-19 Thread Andrew Cooper
On 19/05/2020 15:55, Jan Beulich wrote: > On 19.05.2020 16:29, Andrew Cooper wrote: >> On 19/05/2020 09:14, Jan Beulich wrote: >>> On 18.05.2020 17:38, Andrew Cooper wrote: The reserved_bit_page_fault() paths effectively turn reserved bit faults into a warning, but in the light of L

Re: [PATCH] x86/traps: Rework #PF[Rsvd] bit handling

2020-05-19 Thread Andrew Cooper
On 19/05/2020 15:48, Jan Beulich wrote: > On 19.05.2020 16:11, Andrew Cooper wrote: >> On 19/05/2020 09:34, Jan Beulich wrote: >>> On 18.05.2020 17:38, Andrew Cooper wrote: @@ -1439,6 +1418,18 @@ void do_page_fault(struct cpu_user_regs *regs) if ( unlikely(fixup_page_fault(addr, regs

Re: [PATCH] x86/traps: Rework #PF[Rsvd] bit handling

2020-05-19 Thread Jan Beulich
On 19.05.2020 16:29, Andrew Cooper wrote: > On 19/05/2020 09:14, Jan Beulich wrote: >> On 18.05.2020 17:38, Andrew Cooper wrote: >>> The reserved_bit_page_fault() paths effectively turn reserved bit faults >>> into >>> a warning, but in the light of L1TF, the real impact is far more serious. >>> >

Re: [PATCH] x86/traps: Rework #PF[Rsvd] bit handling

2020-05-19 Thread Jan Beulich
On 19.05.2020 16:11, Andrew Cooper wrote: > On 19/05/2020 09:34, Jan Beulich wrote: >> On 18.05.2020 17:38, Andrew Cooper wrote: >>> @@ -1439,6 +1418,18 @@ void do_page_fault(struct cpu_user_regs *regs) >>> if ( unlikely(fixup_page_fault(addr, regs) != 0) ) >>> return; >>> >>> +

Re: [PATCH] x86/traps: Rework #PF[Rsvd] bit handling

2020-05-19 Thread Andrew Cooper
On 19/05/2020 09:14, Jan Beulich wrote: > On 18.05.2020 17:38, Andrew Cooper wrote: >> The reserved_bit_page_fault() paths effectively turn reserved bit faults into >> a warning, but in the light of L1TF, the real impact is far more serious. >> >> Xen does not have any reserved bits set in its page

Re: [PATCH] x86/traps: Rework #PF[Rsvd] bit handling

2020-05-19 Thread Andrew Cooper
On 19/05/2020 09:34, Jan Beulich wrote: > On 18.05.2020 17:38, Andrew Cooper wrote: >> @@ -1439,6 +1418,18 @@ void do_page_fault(struct cpu_user_regs *regs) >> if ( unlikely(fixup_page_fault(addr, regs) != 0) ) >> return; >> >> +/* >> + * Xen have reserved bits in its pageta

Re: [PATCH] x86/traps: Rework #PF[Rsvd] bit handling

2020-05-19 Thread Jan Beulich
On 18.05.2020 17:38, Andrew Cooper wrote: > @@ -1439,6 +1418,18 @@ void do_page_fault(struct cpu_user_regs *regs) > if ( unlikely(fixup_page_fault(addr, regs) != 0) ) > return; > > +/* > + * Xen have reserved bits in its pagetables, nor do we permit PV guests > to > + *

Re: [PATCH] x86/traps: Rework #PF[Rsvd] bit handling

2020-05-19 Thread Jan Beulich
On 18.05.2020 17:38, Andrew Cooper wrote: > The reserved_bit_page_fault() paths effectively turn reserved bit faults into > a warning, but in the light of L1TF, the real impact is far more serious. > > Xen does not have any reserved bits set in its pagetables, nor do we permit PV > guests to write

Re: [PATCH] x86/traps: Rework #PF[Rsvd] bit handling

2020-05-18 Thread Andrew Cooper
On 18/05/2020 16:38, Andrew Cooper wrote: > The reserved_bit_page_fault() paths effectively turn reserved bit faults into > a warning, but in the light of L1TF, the real impact is far more serious. > > Xen does not have any reserved bits set in its pagetables, nor do we permit PV > guests to write