[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 4/6] xen_pvdev: Do not assume Dom0 when creating a directo

From: David Woodhouse
Subject: Re: [PATCH v2 4/6] xen_pvdev: Do not assume Dom0 when creating a directory
Date: Thu, 23 Nov 2023 11:57:39 +0000
User-agent: K-9 Mail for Android

On 23 November 2023 11:54:01 GMT, Volodymyr Babchuk 
<Volodymyr_Babchuk@epam.com> wrote:
>Hi Paul,
>Paul Durrant <xadimgnik@gmail.com> writes:
>> On 23/11/2023 00:07, Volodymyr Babchuk wrote:
>>> Hi,
>>> Volodymyr Babchuk <volodymyr_babchuk@epam.com> writes:
>>>> Hi Stefano,
>>>> Stefano Stabellini <sstabellini@kernel.org> writes:
>>>>> On Wed, 22 Nov 2023, David Woodhouse wrote:
>>>>>> On Wed, 2023-11-22 at 15:09 -0800, Stefano Stabellini wrote:
>>>>>>> On Wed, 22 Nov 2023, David Woodhouse wrote:
>>>>>>>> On Wed, 2023-11-22 at 14:29 -0800, Stefano Stabellini wrote:
>>>>>>>>> On Wed, 22 Nov 2023, Paul Durrant wrote:
>>>>>>>>>> On 21/11/2023 22:10, Volodymyr Babchuk wrote:
>>>>>>>>>>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>>>>>>>> Instead of forcing the owner to domid 0, use XS_PRESERVE_OWNER to
>>>>>>>>>>> inherit the owner of the directory.
>>>>>>>>>> Ah... so that's why the previous patch is there.
>>>>>>>>>> This is not the right way to fix it. The QEMU Xen support is 
>>>>>>>>>> *assuming* that
>>>>>>>>>> QEMU is either running in, or emulating, dom0. In the emulation case 
>>>>>>>>>> this is
>>>>>>>>>> probably fine, but the 'real Xen' case it should be using the 
>>>>>>>>>> correct domid
>>>>>>>>>> for node creation. I guess this could either be supplied on the 
>>>>>>>>>> command line
>>>>>>>>>> or discerned by reading the local domain 'domid' node.
>>>>>>>>> yes, it should be passed as command line option to QEMU
>>>>>>>> I'm not sure I like the idea of a command line option for something
>>>>>>>> which QEMU could discover for itself.
>>>>>>> That's fine too. I meant to say "yes, as far as I know the toolstack
>>>>>>> passes the domid to QEMU as a command line option today".
>>>>>> The -xen-domid argument on the QEMU command line today is the *guest*
>>>>>> domain ID, not the domain ID in which QEMU itself is running.
>>>>>> Or were you thinking of something different?
>>>>> Ops, you are right and I understand your comment better now. The backend
>>>>> domid is not on the command line but it should be discoverable (on
>>>>> xenstore if I remember right).
>>>> Yes, it is just "~/domid". I'll add a function that reads it.
>>> Just a quick question to QEMU folks: is it better to add a global
>>> variable where we will store own Domain ID or it will be okay to read
>>> domid from Xenstore every time we need it?
>>> If global variable variant is better, what is proffered place to
>>> define
>>> this variable? system/globals.c ?
>> Actually... is it possible for QEMU just to use a relative path for
>> the backend nodes? That way it won't need to know it's own domid, will
>> it?
>Well, it is possible to use relative path, AFAIK, linux-based backends
>are doing exactly this. But problem is with xenstore_mkdir() function,
>which requires domain id to correctly set owner when it causes call to
>As David said, architecturally it will be better to get rid of
>xenstore_mkdir() usage, because it is used by legacy backends only. But
>to do this, someone needs to convert legacy backends to use newer API. I
>have no capacity to do this right now, so I implemented a contained
>static int xenstore_read_own_domid(unsigned int *domid)
>in xen_pvdev.c. I believe, this new function will be removed along with
>whole xen_pvdev.c when there will be no legacy backends left.

Which PV backends do you care about? We already have net, block and console 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]