On Sunday, July 30, 2017 12:23 PM, Michael S. Tsirkin wrote: > On Sat, Jul 29, 2017 at 08:47:08PM +0800, Wei Wang wrote: > > On 07/29/2017 07:08 AM, Michael S. Tsirkin wrote: > > > On Thu, Jul 27, 2017 at 10:50:11AM +0800, Wei Wang wrote: > > > > > > > OK I thought this over. While we might need these new APIs > > > > > > > in the future, I think that at the moment, there's a way to > > > > > > > implement this feature that is significantly simpler. Just > > > > > > > add each s/g as a separate input buffer. > > > > > > Should it be an output buffer? > > > > > Hypervisor overwrites these pages with zeroes. Therefore it is > > > > > writeable by device: DMA_FROM_DEVICE. > > > > Why would the hypervisor need to zero the buffer? > > > The page is supplied to hypervisor and can lose the value that is > > > there. That is the definition of writeable by device. > > > > I think for the free pages, it should be clear that they will be added > > as output buffer to the device, because (as we discussed) they are > > just hints, and some of them may be used by the guest after the report_ API is > invoked. > > The device/hypervisor should not use or discard them. > > Discarding contents is exactly what you propose doing if migration is going on, > isn't it? That's actually a different concept. Please let me explain it with this example: The hypervisor receives the hint saying the guest PageX is a free page, but as we know, after that report_ API exits, the guest kernel may take PageX to use, so PageX is not free page any more. At this time, if the hypervisor writes to the page, that would crash the guest. So, I think the cornerstone of this work is that the hypervisor should not touch the reported pages. Best, Wei
