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