[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ef819e0e-85c3-0b14-4f8e-0d2a6c452355@linux.ibm.com>
Date: Thu, 6 Aug 2020 16:19:23 +0200
From: Pierre Morel <pmorel@...ux.ibm.com>
To: "Michael S. Tsirkin" <mst@...hat.com>,
Jason Wang <jasowang@...hat.com>
Cc: linux-kernel@...r.kernel.org, pasic@...ux.ibm.com,
borntraeger@...ibm.com, frankja@...ux.ibm.com, cohuck@...hat.com,
kvm@...r.kernel.org, linux-s390@...r.kernel.org,
virtualization@...ts.linux-foundation.org, thomas.lendacky@....com,
david@...son.dropbear.id.au, linuxram@...ibm.com,
hca@...ux.ibm.com, gor@...ux.ibm.com
Subject: Re: [PATCH v7 2/2] s390: virtio: PV needs VIRTIO I/O device
protection
On 2020-07-30 13:31, Pierre Morel wrote:
...snip...
>>>> What bothers me here is that arch code depends on virtio now.
>>>> It works even with a modular virtio when functions are inline,
>>>> but it seems fragile: e.g. it breaks virtio as an out of tree module,
>>>> since layout of struct virtio_device can change.
>>>
>>>
>>> The code was only called from virtio.c so it should be fine.
>>>
>>> And my understanding is that we don't need to care about the kABI issue
>>> during upstream development?
>>>
>>> Thanks
>>
>> No, but so far it has been convenient at least for me, for development,
>> to just be able to unload all of virtio and load a different version.
>>
>>
>>>
>>>>
>>>> I'm not sure what to do with this yet, will try to think about it
>>>> over the weekend. Thanks!
After reflection, I am not sure that this problem must be treated on the
architecture level or inside the VIRTIO transport.
Consequently, I will propose another patch series based on CCW transport.
This also should be more convenient for core development.
Regards,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
Powered by blists - more mailing lists