Re: vhost-user(?) breaking changes

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 1991 bytes --]

On 5/27/26 04:20, Alyssa Ross wrote:
> [Trimming CC substantially.]
> 
> Alex Bennée <alex.bennee@linaro.org> writes:
> 
>> Manos Pitsidianakis <manos.pitsidianakis@linaro.org> writes:
>>
>>> On Mon, May 25, 2026 at 5:03 AM Demi Marie Obenour
>>> <demiobenour@gmail.com> wrote:
>>>>
>>>> The first is whether vhost-user memory regions
>>>> are guaranteed to not overlap.  I sent a patch in
>>>> https://lore.kernel.org/qemu-devel/20260522-vhost-user-dev-v1-1-b31646cf19b8@gmail.com
>>>> to guarantee this is not the case.  However, this is technically a
>>>> breaking spec change.  The virtio vhost-user device I'm working on
>>>> requires this.
>>
>> Breaking spec changes are always a red flag because of whats already
>> deployed. Are you sure there is no way to make changes optional with use
>> of feature flags?
> 
> There's some nuance between breaking changes and clarifications though,
> right?  e.g. 97f24a0496 ("vhost-user.rst: clarify when FDs can be sent")
> tightened things up, so could also have been in principle have been seen
> as a breaking change, but not practically.
> 
> Are there likely to be devices that use overlapping memory regions
> today?  Would we expect that to work?

If an address matches more than one region, the current specification
doesn't state which one should be chosen.  I suspect current backends
either pick one arbitrarily or fail.  I don't think either behavior
is particularly useful.

If the frontend never sends an address that matches more than one
region, I expect things will work fine.  However, this means that the
overlapping part cannot be used safely.  I don't think that this is
a useful thing for a frontend to do.

Treating overlapping regions as an error has the advantage of being
testable and well-defined.  Also, this only means that frontends
must not send overlapping regions.  It doesn't require backends to
change behavior.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]