On 18.11.2022 14:00, Marek Marczykowski-Górecki wrote: > On Fri, Nov 18, 2022 at 01:33:39PM +0100, Jan Beulich wrote: >> On 18.11.2022 13:19, Marek Marczykowski-Górecki wrote: >>> On Fri, Nov 18, 2022 at 08:20:14AM +0100, Jan Beulich wrote: >>>> On 17.11.2022 18:31, Marek Marczykowski-Górecki wrote: >>>>> On Thu, Nov 17, 2022 at 05:34:36PM +0100, Jan Beulich wrote: >>>>>> Which in turn raises the question: Do you need to handle reads >>>>>> in the new code in the first place? >>>>> >>>>> The page not being mapped is also the reason why I do need to handle >>>>> reads too. >>>> >>>> Just for my own clarity: You mean "not mapped to qemu" here? >>> >>> No, to the HVM domain (in p2m). Xen (outside of MSI-X specific code for >>> HVM) doesn't know where those reads should be from. >> >> Hmm, I was expecting them to be mapped r/o to the guest, but perhaps I'm >> misremembering. Clearly both ept_p2m_type_to_flags() and >> p2m_type_to_flags() take mmio_ro_ranges into consideration, which is >> what I was basing my understanding on (without having looked at other >> places in detail). > > Qemu doesn't map the page (using xc_domain_memory_mapping()) where MSI-X > table lives. I tried to modify this part, but it resulted in EPT > violation on write attempt (and my emulation code wasn't called at all).
Well, yes - that leads to the other path I pointed you at, which is used for both HVM and PV (and which, as per what you say, then looks to be relevant for PVH only right now). Jan
