>>> On 09.04.19 at 11:50, <julien.gr...@arm.com> wrote: > On 08/04/2019 15:29, Jan Beulich wrote: >>>>> On 08.04.19 at 13:47, <julien.gr...@arm.com> wrote: >>> de-allocation step aside, I am not really convinced you can reuse >>> guest_remove_page() here. On x86, the function will not work on certain >>> p2m types. Is it what we really want? >> >> Hmm, I'm confused. Afaics the only two types it refuses a request >> for are p2m_invalid and p2m_mmio_dm. These represent cases >> where there's no p2m entry anyway, i.e. nothing to remove. Am >> I perhaps overlooking something you see? >> >> Or are you referring to the mfn_invalid() check (which isn't x86- >> specific)? This ought to be covered by the p2m_is_paging() and >> p2m_mmio_direct special cases a few lines up from there. Other >> cases with invalid MFNs would indeed represent an error condition >> imo. > > I am referring to get_page(...) which would not work for foreign pages.
Ah, that's part of the de-allocation portion of the code, which I've previously indicated would need to be skipped in the case here. >> In the end it's actually quite the opposite that I'm thinking: For >> the caller it shouldn't, for example, matter whether the >> requested page was paged out. We wouldn't even call >> guest_physmap_remove_page() in that case, while >> guest_remove_page() would take care of it. > > But those pages should never be removed via physmap, I am correct? The guest is unaware of paging, so as long as it's permitted to use this hypercall, it should make no difference to it whether a page is actually in memory at the time it issues this hypercall. > Anyway, guest_physmap_remove_page() would need some rework to do the correct > things for physmap. Of course. > I will wait an see your patch to comment. Well, the reason for the TBD item in the patch here was precisely to figure out whether creating such a patch would make sense, or whether the current use of guest_physmap_remove_page() is correct. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
