Re: [XEN v9 3/4] xen/arm64: io: Handle the abort due to access to stage1 translation table

[Julien Grall <julien@xxxxxxx>]

Hi,

On 08/03/2022 11:22, Ayan Kumar Halder wrote:
> Hi Julien,
>
> On 07/03/2022 23:59, Julien Grall wrote:
> > Hi,
> >
> > On 07/03/2022 22:23, Ayan Kumar Halder wrote:
> > > On 07/03/2022 19:37, Julien Grall wrote:
> > > > On 07/03/2022 14:27, Ayan Kumar Halder wrote:
> > > > > Hi Julien,
> > > > Hi Ayan,
> > > Hi Julien,
> > >
> > > I need a bit of clarification to understand this.
> > >
> > > > > One clarification.
> > > > >
> > > > > On 04/03/2022 10:39, Julien Grall wrote:
> > > > > > Hi Ayan,
> > > > > >
> > > > > > On 01/03/2022 12:40, Ayan Kumar Halder wrote:
> > > > > > > If the abort was caused due to access to stage1 translation 
> > > > > > > table, Xen
> > > > > > > will assume that the stage1 translation table is in the non MMIO 
> > > > > > > region.
> > > > Reading this commit message again. I think you want to explain why 
> > > > we want to do that because, from my understanding, this is 
> > > > technically not forbidden by the Arm Arm.
> > > > From the previous discussion, we want to do this because we can't 
> > > > easily handle such fault on emulated region (we have no away to the 
> > > > walker the value read).
> > > Sorry, Can you explain this a bit more ? Do you mean that if the page 
> > > table is located in the emulated region, map_domain_page() (called 
> > > from p2m_next_level()) will fail.
> > For data abort with valid syndrome, you will have a register to write 
> > back the value read. When the data abort has s1ptw == 1, AFAICT, we 
> > have no information how to return the value.
> Do you mean that for s1ptw, we get an intermediate physical address ?
>
>      if ( hpfar_is_valid(xabt.s1ptw, fsc) )
>          gpa = get_faulting_ipa(gva);
No. That's not relevant here. We always need a IPA in order to deal with 
the fault.
> If the IPA corresponds to an emulated region, then Xen can read the 
> emulated address, but can't return the value to the guest OS.
That wouldn't be the guest OS. But the page-table walker in the CPU.

> > > Can Linux or any OS keep its page tables in the direct MMIO space ? 
> > > If yes, then try_map_mmio() needs to be invoked to map the region, so 
> > > that OS can access it. If not, then Xen needs to return abort because 
> > > the OS may be behaving maliciously.
> > I think what matters is whether the Arm Arm would or would not allow 
> > it. From what I can tell there are no such restriction. So we would 
> > need to be cautious to restrict it further than necessary.
> > > My understanding from previous discussion was that it does not make 
> > > sense for linux or any OS to keep its page tables in any MMIO region 
> > > (emulated or direct). Please correct me if mistaken.
> > At the moment, none of the regions emulated by Xen could be used for 
> > page-tables. I am also not sure how we should handle such access if 
> > they arise. So it is more convenient to simply forbid them.
> > Regarding direct MMIO, see above. Correct me if I am wrong, but it 
> > should not be a problem for Xen to deal with them. So while I agree 
> > this doesn't seem to make sense, the restriction seems unnecessary.
> So the behavior will be :-
>
> 1. If the stage1 translation table is in the non MMIO region or 'direct 
> mapped' MMIO region, then invoke p2m_resolve_translation_fault() and 
> try_map_mmio() to resolve the fault. If it succeeds, then return to the 
> guest to retry.
When 1. happens we don't know yet if the stage1 will be a non MMIO 
region or 'direct mapped'. Instead, we only know that the ISS syndrome 
is invalid.
If it is a prefetch abort or the syndrome is invalid, then we should 
call check_p2m().
> 2. If the previous step fails and for any other scenario (ie stage1 
> translation table is in emulated MMIO region or the address is invalid), 
> return the abort to the guest.
If check_p2m() didn't success and it is a fault on stage-1 walk, then we 
should send an abort.
Cheers,

--
Julien Grall