> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Friday, March 8, 2019 1:44 AM > > > > > > > This kind of data needs to be saved / loaded in pre-copy and > > > > stop-and-copy phase. > > > > The data of device memory is held in device memory region. > > > > Size of devie memory is usually larger than that of device > > > > memory region. qemu needs to save/load it in chunks of size of > > > > device memory region. > > > > Not all device has device memory. Like IGD only uses system > memory. > > > > > > It seems a little gratuitous to me that this is a separate region or > > > that this data is handled separately. All of this data is opaque to > > > QEMU, so why do we need to separate it? > > hi Alex, > > as the device state interfaces are provided by kernel, it is expected to > > meet as general needs as possible. So, do you think there are such use > > cases from user space that user space knows well of the device, and > > it wants kernel to return desired data back to it. > > E.g. It just wants to get whole device config data including all mmios, > > page tables, pci config data... > > or, It just wants to get current device memory snapshot, not including any > > dirty data. > > Or, It just needs the dirty pages in device memory or system memory. > > With all this accurate query, quite a lot of useful features can be > > developped in user space. > > > > If all of this data is opaque to user app, seems the only use case is > > for live migration. > > I can certainly appreciate a more versatile interface, but I think > we're also trying to create the most simple interface we can, with the > primary target being live migration. As soon as we start defining this > type of device memory and that type of device memory, we're going to > have another device come along that needs yet another because they have > a slightly different requirement. Even without that, we're going to > have vendor drivers implement it differently, so what works for one > device for a more targeted approach may not work for all devices. Can > you enumerate some specific examples of the use cases you imagine your > design to enable? >
Do we want to consider an use case where user space would like to selectively introspect a portion of the device state (including implicit state which are not available through PCI regions), and may ask for capability of direct mapping of selected portion for scanning (e.g. device memory) instead of always turning on dirty logging on all device state? Thanks Kevin
