[Virtio-fs] [PATCH v3 1/1] vhost-user-fs: add migration type property

[Anton Kuchin]

On 06/03/2023 23:53, Michael S. Tsirkin wrote:
> On Mon, Mar 06, 2023 at 10:55:29PM +0200, Anton Kuchin wrote:
>> On 01/03/2023 22:22, Michael S. Tsirkin wrote:
>>> On Wed, Mar 01, 2023 at 09:35:56PM +0200, Anton Kuchin wrote:
>>>> I do trust them :)
>>>> I have to, otherwise we would need to pack all the properties and
>>>> flags of qemu to the migration stream and validate them at
>>>> destination or entire migration ends up broken beyond repair if
>>>> orchestrators tend to do stupid things and need babysitting.
>>> This is not at all a crazy idea. It has some disadvantages
>>> too esp around cross version migration, which is why we
>>> don't do this yet.
>>>
>> Indeed. I know VMMs that chose this path. But as long as
>> qemu decided to trust orchestrators I think we'd better
>> keep this consistent across the codebase.
>>
>> Only ivshmem_pre_load callback bothers to check device
>> property and virtio_net_tx_waiting_pre_load checks that
>> number of queue pairs doesn't exceed allowed maximum, all
>> other *_pre_load functions generally just initialize some
>> parts of state that need to be set before stream starts
>> loading.
> We do validate things by necessity we just try to do
> as much as we can table-driver so it's not open-coded
> and less visible. We used to have lot more callbacks
> nowdays we try to keep it table driven.
> But e.g. pci streams RO state and validates that it's the same
> on destination.
>

Sorry for late reply. I agree that checks should be done if
we have data at hand.
But in my opinion the situation here is a little different:
pci is emulated by qemu and RO state affects how emulation
will work on destination, the point of vhost-user is to
outsource device emulation logic to daemons outside qemu and
allow orchestrator manage both qemu and daemons.
So engineering additional flags in qemu that don't affect
device operation but only to check orchestrator correctness
is excessive in my opinion.