On Sat, Sep 08, 2012 at 02:36:00PM +0930, Rusty Russell wrote: > "Michael S. Tsirkin" <mst@xxxxxxxxxx> writes: > > On Fri, Sep 07, 2012 at 04:09:50PM +0930, Rusty Russell wrote: > >> > So it looks like a bug: we should teach driver to tell host first on leak? > >> > Yan, Vadim, can you comment please? > >> > > >> > Also if true, looks like this bit will be useful to detect a fixed driver on > >> > the hypervisor side - to avoid unmapping such pages? Rusty what do you > >> > think? > >> > >> So, feature is unimplemented in qemu, and broken in drivers. I starting > >> to share Paolo's dislike of it. > > > > What is broken in drivers? > > Because supporting the feature is *not* optional for a driver. > > If the device said MUST_TELL_HOST, it meant that the driver *had* to > tell the host before it touched the page, otherwise Bad Things might > happen. It was in the original spec precisely to allow devices to > actually *remove* pages. > > Noone ever noticed the windows driver didn't support it, because qemu > never requires MUST_TELL_HOST. > > So in practice, it's now an optional feature. Since no device used it > anyway, we're better off discarding it than trying to fix it. I trust you this was not the intent. But it seems to be the intent in spec, because almost all features are optional. And so windows driver authors interpreted it this way. And it is *useful* like this. See below. > If someone wants an *optional* "tell me first" feature later, that's > easy to add, but I don't see why they'd want to. Suggested use is for device assignment which needs all guest memory locked. hypervisor can unlock pages in balloon but guest must wait for hypervisor to lock them back before use. when a hypervisor implements this, this will work with linux guests but not windows guests and the existing bit fits exactly the purpose. > > Do we really know there are no hypervisors implementing it? > > As much as can be known. Qemu doesn't, lkvm doesn't. But we can add it in qemu and it will be a useful feature. > > As I said above drivers do have support. > > Not the windows drivers. So it's optional, thus removing it will likely > harm noone. > > Cheers, > Rusty. I think the issue is that kvm always locked all guest memory for assignment. This restriction is removed with vfio which has separate page tables. Now that vfio is upstream and work on qemu integration is being worked on, we might finally see people using this bit to allow memory overcommit with device assignment. So let's not remove yet, there is no rush. Let's document it that this feature is optional, maybe renaming as Paolo suggests. -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
