OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Dirty Page Tracking (DPT)


I understand that DPT isn't really on the forefront of the vDPA framework, but wanted to understand if there any initial thoughts on how this would work...

In the migration framework, in its simplest form, (I gather) its QEMU via KVM that is reading the dirty page table, converting bits to page numbers, then flushing remote VM/copying local page(s)->remote VM, ect.Â

While this is fine for a VM (say VM1) dirtying its own memory and the accesses are trapped in the kernel as well as the log is being updated, I'm not sure what happens in the situationÂof vhost, where a remote VM (say VM2) is dirtying up VM1's memory since it can directly access it, during packet reception for example.

Whatever technique is employedÂto catch this, how would this differ from a HW based Virtio device doing DMA directly into a VM's DDR, wrt to DPT? Is QEMU going to have a 2nd place to query the dirty logs - ie: the vDPA layer?

Further I heard about a SW based DPT within the vDPA framework for those devices that do not (yet) support DPT inherently in HW. How is this envisioned to work?

Finally, for those HW vendors that do support DPT in HW, a mapping of a bit -> page isn't really an option, since no one wants to do a byte wide read-modify-write across the PCI bus, but rather map a whole byte to page is likely more desirable - the HW can just do non-posted writes to the dirty page table. If byte wise, then the QEMU/vDPA layer has to either fix-up the mapping (from byte->bit) or have the capability to handle the granularity diffs.

Thoughts?

Rob Miller
(919)721-3339


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]