> -----Original Message----- > From: Jan Beulich <jbeul...@suse.com> > Sent: 31 July 2020 14:41 > To: p...@xen.org > Cc: xen-devel@lists.xenproject.org; 'Paul Durrant' <pdurr...@amazon.com>; > 'Andrew Cooper' > <andrew.coop...@citrix.com>; 'Wei Liu' <w...@xen.org>; 'Roger Pau Monné' > <roger....@citrix.com> > Subject: Re: [PATCH v2 2/2] x86/hvm: simplify 'mmio_direct' check in > epte_get_entry_emt() > > On 31.07.2020 15:07, Paul Durrant wrote: > >> -----Original Message----- > >> From: Jan Beulich <jbeul...@suse.com> > >> Sent: 31 July 2020 13:58 > >> To: Paul Durrant <p...@xen.org> > >> Cc: xen-devel@lists.xenproject.org; Paul Durrant <pdurr...@amazon.com>; > >> Andrew Cooper > >> <andrew.coop...@citrix.com>; Wei Liu <w...@xen.org>; Roger Pau Monné > >> <roger....@citrix.com> > >> Subject: Re: [PATCH v2 2/2] x86/hvm: simplify 'mmio_direct' check in > >> epte_get_entry_emt() > >> > >> On 31.07.2020 14:39, Paul Durrant wrote: > >>> From: Paul Durrant <pdurr...@amazon.com> > >>> > >>> Re-factor the code to take advantage of the fact that the APIC access > >>> page is > >>> a 'special' page. > >> > >> Hmm, that's going quite as far as I was thinking to go: In > >> particular, you leave in place the set_mmio_p2m_entry() use > >> in vmx_alloc_vlapic_mapping(). With that replaced, the > >> re-ordering in epte_get_entry_emt() that you do shouldn't > >> be necessary; you'd simple drop the checking of the > >> specific MFN. > > > > Ok, it still needs to go in the p2m though so are you suggesting > > just calling p2m_set_entry() directly? > > Yes, if this works. The main question really is whether there are > any hidden assumptions elsewhere that this page gets mapped as an > MMIO one. >
Actually, it occurs to me that logdirty is going to be an issue if I use p2m_ram_rw. If I'm not going to use p2m_mmio_direct then do you have another suggestion? Paul
