Hi,
On 01/02/2022 19:06, Ayan Kumar Halder wrote:
As you pointed out previously, the field SAS (Syndrome Access Size) is
invalid when the ISV=0. So the decoding needs to be done *before* we
select the IOREQ server.
But as I said, this would result to decode the instruciton when this
is not necessary. This is where Stefano's suggestion in [1] is useful.
For ISV=0, it will be a lot more common to trap because of a P2M
translation fault (of the MMIO is not mapped). So we should call that
first and then, if it still not resolved, try to decode the instruction.
With that in place, you are avoiding the issue in try_fwd_ioserv().
Can you please coordinate with Stefano?
Can you let me know which suggestion Julien is referring here ?
[1] does not point to a valid url.
This is a message-id. They are unique, so you can easily find the
message on public archives (e.g. lore.kernel.org) or in your inbox.
I tend to use lore.kernel.org for the archives. The URL looks like:
https://lore.kernel.org/<ml>/<message-id>
In your case, <ml> would be xen-devel (they also archives may other MLs)
and the <message-id> would be the one I put in [1].
The message-id can be really useful if you use it in combination of
tools like b4 [1]. With a single ID, it allows you to pull a series,
fetch tags and then you can apply with 'git am'.
Cheers,
[1]
https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation
--
Julien Grall
