>>> I'll need to think about this. >>> We need to remember that the whole HINT thing is not a mandate for host to >>> corrupt memory. It's just some info about page use guest >>> gives host. If host corrupts memory it's broken ... >> >> I don't think that's true, > > Do you refer to "If host corrupts memory it's broken"? > You think that's not true? Let me think this through. IMHO it's a "hint with the option for the hypervisor to assume the content is X and optimize (e.g., not migrate a page) unless the page is reused before hinting ends". Whereby X is currently assumed to be 0, correct? Assume migrated starts, guest hints a page, migration ends. Guest reads the page again. a) It could be the original page (still migrated) b) It could be the zero page (not migrated). And I think that's a valid corruption of the page content, no? Now, it's more tricky when we have the following Migrated starts, guest hints a page, guest reuses the page (e.g., writes first byte), migration ends. Guest reads the page again. Here, I (hope) always the original page content is maintained via the 2-bitmap magic. Or am I missing something important? > >> and that's not what we currently implement in >> the hypervisor for speeding up migration. I still consider >> VIRTIO_BALLOON_F_FREE_PAGE_HINT as an alternative technique of >> temporarily inflating/deflating. > > Reporting is like that. But hinting isn't, simply because > by the time host gets the hint page may already be in use. > Blowing it out unconditionally would lead to easily > reproducible guest crashes. Agreed that the semantics are different. But "eventually getting a zero page after migration" was part of the whole invention, no? That's the whole point of the optimization. > >> E.g., we don't migrate any of these >> pages in the hypervisor, so the content will be zeroed out on the >> migration target. > > Not exactly true. We do a delicate play with > the two dirty bits so they *are* migrated sometimes. Agreed. Will something like this catch the semantics? "Pages hinted via VIRTIO_BALLOON_F_FREE_PAGE_HINT will always have the original page content when written before hinting stops. However, if pages are not written before hinting stops, the hypervisor might replace them by a zero page." > >> If migration fails, the ld content will remain. You >> can call that "corrupting memory" - it's exactly what it has been >> invented for. > > Well no, original author repeatedly stated it's "hinting" > because page can be in use actually. Agreed. > >> >> IIRC we decided to glue the semantics of VIRTIO_BALLOON_F_PAGE_POISON to >> VIRTIO_BALLOON_F_FREE_PAGE_HINT, which makes in my opinion perfect sense. >> >> So I propose: >> >> VIRTIO_BALLOON_F_PAGE_POISON not implemented in the hypervisor: >> - Pages inflated/deflated via VIRTIO_BALLOON_F_FREE_PAGE_HINT will >> either have the old page content or will be filled with 0. >> - This matches what we currently do. >> >> VIRTIO_BALLOON_F_PAGE_POISON implemented in the hypervisor: >> - Pages inflated/deflated via VIRTIO_BALLOON_F_FREE_PAGE_HINT will >> either have the old page content or will be filled with poison_val. >> - This matches what we should do also during ordinary >> inflation/deflation and free page reporting. > > It's a reasonable option. however ... > >> Again, nothing is currently broken as we free_page() the pages and don't >> care about an eventually changed page content. > > I don't see how you can say that. ATM on a host without POISON > and with HINT, with poison val != 0 and with validation, > host can blow a free page away and then guest will detect > that as corruption. (At this point I start to hate the whole free page hinting feature again :D It starts messing with my brain again.) As soon as we do the free_page(), the page will be written to and definitely get migrated, right? If the hypervisor would blow out the page after the free_page(), we would be in trouble. What am I missing? -- Thanks, David / dhildenb _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
