lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 07 Sep 2012 14:22:47 +0200
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	"Michael S. Tsirkin" <mst@...hat.com>
CC:	Rusty Russell <rusty@...tcorp.com.au>, fes@...gle.com,
	aarcange@...hat.com, riel@...hat.com, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org, mikew@...gle.com, yinghan@...gle.com,
	virtualization@...ts.linux-foundation.org, yvugenfi@...hat.com,
	vrozenfe@...hat.com
Subject: Re: [PATCH] virtio-balloon spec: provide a version of the "silent
 deflate" feature that works

Il 07/09/2012 14:17, Michael S. Tsirkin ha scritto:
>>> Next, consider the interface proposed here. You defacto declare
>>> all existing drivers buggy.
>>
>> No, only Windows (and it is buggy, it calls tell_host last).
> 
> It is not buggy. It does not ack MUST_TELL_HOST. So it is free to tell
> host at any point, it behaves exactly
> to spec. You can not retroactively declare drivers buggy like that.

Well, according to your reading of the spec.

In the spec I'm reading "Host must be told before pages from the balloon
are used".  Doesn't say anything about the guest.

Now, indeed a very free interpretation is "Guest will tell host before
pages from the balloon are used".  It turns out that it's exactly what
guests have been doing, hence that's exactly what I'm proposing now:
rename the feature to VIRTIO_BALLOON_F_WILL_TELL_HOST.

>> True, but the choice is:
>>
>> 1) add a once-only hack to QEMU that fixes migration of
>> VIRTIO_BALLOON_F_MUST_TELL_HOST;
>>
>> 2) always advertise VIRTIO_BALLOON_F_MUST_TELL_HOST.  If you do this,
>> guests cannot use anymore silent deflate, which is a regression.
>>
>> 3) use two bits.  One tells the device that the driver supports chatty
>> deflate; one tells the driver that the device supports silent deflate.
> 
> The right thing to do is either
> 4. realize we can not address all user errors, so no real issue
> 5. address this class of user errors by migrating host features
> 
>> So in the end you do use two feature bits for two different things.
>> Plus, both feature bits are "positive" and I'm happy.
> 
> I am not happy.
> We lose compatibility with all existing drivers

How so?

> so it will take years until the feature is actually
> useful.

No, we don't!  Windows guests will just not be able to use munlock/mlock
until the driver is fixed.  Which will probably happen before someone
writes the munlock/mlock code.

> Is this just a matter of naming? Same functionality:
> driver that acks this bit will tell host first,
> driver that does not will not?
> 
> If yes that is fine.

Yes, that part we agree on I think.  We disagree that (after the rename)
QEMU should start always proposing VIRTIO_BALLOON_F_WILL_TELL_HOST.

_Plus_ adding the new feature bit, which is needed to actually tell the
driver that the host supports the silent deflate.  Spec patch on the way.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ