linux-kernel - Re: [PATCH 0/2] virtio-balloon: make it spec compliant

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]

Message-ID: <20240705073122-mutt-send-email-mst@kernel.org>
Date: Fri, 5 Jul 2024 07:38:42 -0400
From: "Michael S. Tsirkin" <mst@...hat.com>
To: David Hildenbrand <david@...hat.com>
Cc: linux-kernel@...r.kernel.org,
	Alexander Duyck <alexander.h.duyck@...ux.intel.com>,
	Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 0/2] virtio-balloon: make it spec compliant

On Fri, Jul 05, 2024 at 01:00:50PM +0200, David Hildenbrand wrote:
> On 05.07.24 12:19, Michael S. Tsirkin wrote:
> > On Fri, Jul 05, 2024 at 12:15:30PM +0200, David Hildenbrand wrote:
> > > On 05.07.24 12:08, Michael S. Tsirkin wrote:
> > > > Currently, if VIRTIO_BALLOON_F_FREE_PAGE_HINT is off but
> > > > VIRTIO_BALLOON_F_REPORTING is on, then the reporting vq
> > > > gets number 3 while spec says it's number 4.
> > > > It happens to work because the qemu virtio pci driver
> > > > is *also* out of spec.
> > > 
> > > I have to ask the obvious: maybe the spec is wrong and we have to refine
> > > that?
> > 
> > Well having vq function shift depending on features is certainly
> > messy ...
> 
> Right, but that's how all of this started from the beginning.
> 
> > How do we know no one implemented the spec as written though?
> 
> I understand that concern, IIUC it would imply that:
> 
> a) In case of a hypervisor, we never ran with a Linux guest
> b) In case of a guest, we never ran under QEMU

Or maybe VIRTIO_BALLOON_F_FREE_PAGE_HINT is set.



> It's certainly possible, although I would assume that most other
> implementation candidates (e.g., cloud-hypervisor) would have complained by
> now about Linux issues.

They either set VIRTIO_BALLOON_F_FREE_PAGE_HINT or followed linux bug to
work around.





> What's your experience: if someone would actually implement it according to
> the spec, would they watch out on the virtio mailing lists for changes (or
> even be able to vote) and would be able to comment that adjusting the spec
> to the real first implementation is wrong?

Unfortunately my experience is that it's not that likely :(


Whatever we do, we need to take existing setups into account.

How would we do it in the spec without breaking working setups?  I guess
we could say that both behaviours are legal.  That would still mean we
need the qemu and linux patches, right?

-- 
MST