search for: page_poisoning_zero

...p;& > + !IS_ENABLED(CONFIG_PAGE_POISONING_NO_SANITY))) > + walk_free_mem_block(vb, 0, &virtio_balloon_send_free_pages); > /* > * End by sending the stop id to the host with an outbuf. Use the > * non-batching mode here to trigger a kick after adding the stop id. PAGE_POISONING_ZERO is actually OK. But I really would prefer it that we still send pages to host, otherwise debugging becomes much harder. And it does not have to be completely useless, even though you can not discard them as they would be zero-filled then. How about a config field telling host what should be ther...

...p;& > + !IS_ENABLED(CONFIG_PAGE_POISONING_NO_SANITY))) > + walk_free_mem_block(vb, 0, &virtio_balloon_send_free_pages); > /* > * End by sending the stop id to the host with an outbuf. Use the > * non-batching mode here to trigger a kick after adding the stop id. PAGE_POISONING_ZERO is actually OK. But I really would prefer it that we still send pages to host, otherwise debugging becomes much harder. And it does not have to be completely useless, even though you can not discard them as they would be zero-filled then. How about a config field telling host what should be ther...

..._NO_SANITY))) > > > + walk_free_mem_block(vb, 0, &virtio_balloon_send_free_pages); > > > /* > > > * End by sending the stop id to the host with an outbuf. Use the > > > * non-batching mode here to trigger a kick after adding the stop id. > > PAGE_POISONING_ZERO is actually OK. > > > > But I really would prefer it that we still send pages to host, > > otherwise debugging becomes much harder. > > > > And it does not have to be completely useless, even though > > you can not discard them as they would be zero-filled then...

..._NO_SANITY))) > > > + walk_free_mem_block(vb, 0, &virtio_balloon_send_free_pages); > > > /* > > > * End by sending the stop id to the host with an outbuf. Use the > > > * non-batching mode here to trigger a kick after adding the stop id. > > PAGE_POISONING_ZERO is actually OK. > > > > But I really would prefer it that we still send pages to host, > > otherwise debugging becomes much harder. > > > > And it does not have to be completely useless, even though > > you can not discard them as they would be zero-filled then...

...ENABLED(CONFIG_PAGE_POISONING_NO_SANITY))) >> + walk_free_mem_block(vb, 0, &virtio_balloon_send_free_pages); >> /* >> * End by sending the stop id to the host with an outbuf. Use the >> * non-batching mode here to trigger a kick after adding the stop id. > PAGE_POISONING_ZERO is actually OK. > > But I really would prefer it that we still send pages to host, > otherwise debugging becomes much harder. > > And it does not have to be completely useless, even though > you can not discard them as they would be zero-filled then. > > How about a config f...

...nk there's an issue here: if pages are poisoned and hypervisor >> subsequently drops them, testing them after allocation will >> trigger a false positive. >> >> The specific configuration: >> >> PAGE_POISONING on >> PAGE_POISONING_NO_SANITY off >> PAGE_POISONING_ZERO off >> >> >> Solutions: >> 1. disable the feature in that configuration >> suggested as an initial step > > Thanks for the finding. > Similar to this option: I'm thinking could we make > walk_free_mem_block() simply return if that option is on? &gt...

...nk there's an issue here: if pages are poisoned and hypervisor >> subsequently drops them, testing them after allocation will >> trigger a false positive. >> >> The specific configuration: >> >> PAGE_POISONING on >> PAGE_POISONING_NO_SANITY off >> PAGE_POISONING_ZERO off >> >> >> Solutions: >> 1. disable the feature in that configuration >> suggested as an initial step > > Thanks for the finding. > Similar to this option: I'm thinking could we make > walk_free_mem_block() simply return if that option is on? &gt...

...;free_page_vq); > + report_free_page_end(vb); > +} > + I think there's an issue here: if pages are poisoned and hypervisor subsequently drops them, testing them after allocation will trigger a false positive. The specific configuration: PAGE_POISONING on PAGE_POISONING_NO_SANITY off PAGE_POISONING_ZERO off Solutions: 1. disable the feature in that configuration suggested as an initial step 2. pass poison value to host so it can validate page content before it drops it 3. pass poison value to host so it can init allocated pages with that value In fact one nice side effect would be that unma...

...;free_page_vq); > + report_free_page_end(vb); > +} > + I think there's an issue here: if pages are poisoned and hypervisor subsequently drops them, testing them after allocation will trigger a false positive. The specific configuration: PAGE_POISONING on PAGE_POISONING_NO_SANITY off PAGE_POISONING_ZERO off Solutions: 1. disable the feature in that configuration suggested as an initial step 2. pass poison value to host so it can validate page content before it drops it 3. pass poison value to host so it can init allocated pages with that value In fact one nice side effect would be that unma...

...ubsequently drops them, testing them after allocation > > > > will trigger a false positive. > > > > > > > > The specific configuration: > > > > > > > > PAGE_POISONING on > > > > PAGE_POISONING_NO_SANITY off > > > > PAGE_POISONING_ZERO off > > > > > > > > > > > > Solutions: > > > > 1. disable the feature in that configuration > > > > suggested as an initial step > > > > > > Thanks for the finding. > > > Similar to this option: I'm think...

...ubsequently drops them, testing them after allocation > > > > will trigger a false positive. > > > > > > > > The specific configuration: > > > > > > > > PAGE_POISONING on > > > > PAGE_POISONING_NO_SANITY off > > > > PAGE_POISONING_ZERO off > > > > > > > > > > > > Solutions: > > > > 1. disable the feature in that configuration > > > > suggested as an initial step > > > > > > Thanks for the finding. > > > Similar to this option: I'm think...

...n new pages are allocated and checked on the destination. This patch adds a config field, poison_val. Guest writes to the config field to tell the host about the poisoning value. The value will be 0 in the following cases: 1) PAGE_POISONING_NO_SANITY is enabled; 2) page poisoning is disabled; or 3) PAGE_POISONING_ZERO is enabled. Signed-off-by: Wei Wang <wei.w.wang at intel.com> Suggested-by: Michael S. Tsirkin <mst at redhat.com> Cc: Michal Hocko <mhocko at suse.com> --- drivers/virtio/virtio_balloon.c | 8 ++++++++ include/uapi/linux/virtio_balloon.h | 2 ++ 2 files changed, 10 insertio...

...gt;> +} >> + > I think there's an issue here: if pages are poisoned and hypervisor > subsequently drops them, testing them after allocation will > trigger a false positive. > > The specific configuration: > > PAGE_POISONING on > PAGE_POISONING_NO_SANITY off > PAGE_POISONING_ZERO off > > > Solutions: > 1. disable the feature in that configuration > suggested as an initial step Thanks for the finding. Similar to this option: I'm thinking could we make walk_free_mem_block() simply return if that option is on? That is, at the beginning of the function:...

...d and hypervisor > > > subsequently drops them, testing them after allocation will > > > trigger a false positive. > > > > > > The specific configuration: > > > > > > PAGE_POISONING on > > > PAGE_POISONING_NO_SANITY off > > > PAGE_POISONING_ZERO off > > > > > > > > > Solutions: > > > 1. disable the feature in that configuration > > > suggested as an initial step > > > > Thanks for the finding. > > Similar to this option: I'm thinking could we make walk_free_mem_block...

This patch series is separated from the previous "Virtio-balloon Enhancement" series. The new feature, VIRTIO_BALLOON_F_FREE_PAGE_VQ, implemented by this series enables the virtio-balloon driver to report hints of guest free pages to the host. It can be used to accelerate live migration of VMs. Here is an introduction of this usage: Live migration needs to transfer the VM's memory

This patch series is separated from the previous "Virtio-balloon Enhancement" series. The new feature, VIRTIO_BALLOON_F_FREE_PAGE_VQ, implemented by this series enables the virtio-balloon driver to report hints of guest free pages to the host. It can be used to accelerate live migration of VMs. Here is an introduction of this usage: Live migration needs to transfer the VM's memory

This patch series enhances the existing virtio-balloon with the following new features: 1) fast ballooning: transfer ballooned pages between the guest and host in chunks using sgs, instead of one array each time; and 2) free page block reporting: a new virtqueue to report guest free pages to the host. The second feature can be used to accelerate live migration of VMs. Here are some details: Live

This patch series enhances the existing virtio-balloon with the following new features: 1) fast ballooning: transfer ballooned pages between the guest and host in chunks using sgs, instead of one array each time; and 2) free page block reporting: a new virtqueue to report guest free pages to the host. The second feature can be used to accelerate live migration of VMs. Here are some details: Live

This patch series enhances the existing virtio-balloon with the following new features: 1) fast ballooning: transfer ballooned pages between the guest and host in chunks using sgs, instead of one array each time; and 2) free page block reporting: a new virtqueue to report guest free pages to the host. The second feature can be used to accelerate live migration of VMs. Here are some details: Live

This patch series enhances the existing virtio-balloon with the following new features: 1) fast ballooning: transfer ballooned pages between the guest and host in chunks using sgs, instead of one array each time; and 2) free page block reporting: a new virtqueue to report guest free pages to the host. The second feature can be used to accelerate live migration of VMs. Here are some details: Live