Hi Julien,
I have a question.
On 04/03/2022 12:49, Julien Grall wrote:
On 04/03/2022 12:13, Ayan Kumar Halder wrote:
Hi Julien,
Hi,
On 04/03/2022 10:46, Julien Grall wrote:
Hi Ayan,
On 01/03/2022 12:40, Ayan Kumar Halder wrote:
When the data abort is caused due to cache maintenance for an address,
there are two scenarios:-
1. Address belonging to a non emulated region - For this, Xen should
set the corresponding bit in the translation table entry to valid and
return to the guest to retry the instruction. This can happen
sometimes
as Xen need to set the translation table entry to invalid. (for eg
'Break-Before-Make' sequence).
2. Address belongs to an emulated region - Xen should ignore the
instruction (ie increment the PC) and return to the guest.
I would be explicit and say something along the lines:
"Xen doesn't cache data for emulated regions. So we can safely
ignore them".
There is a third scenarios:
The address belongs to neither an emulated region nor has a valid
mapping in the P2M.
To check this, we should test "try_handle_mmio() == IO_UNHANDLED". If
so then send an abort to the guest.
Is this correct ?
I think it would be too late because if the region is emulated, then
we would have already tried to handle it.
Instead, I think we need to check after we confirmed that the region
is emulated or we need to forward to an IOREQ server.
So the check would have to be duplicated here.
When do we know that a particular address does not belong to an emulated
MMIO region ?
Is this after both "find_mmio_handler()" and "ioreq_server_select()"
have returned NULL ?
- Ayan
Cheers,
