Re: [Qemu-devel] One question to lowlevel/xl/xl.c and lowlevel/xc/xc.c

["Chen, Tiejun" <tiejun.chen@intel.com>]

On 2015/3/24 18:20, Ian Campbell wrote:
> On Tue, 2015-03-24 at 18:15 +0800, Chen, Tiejun wrote:
>> On 2015/3/24 17:51, Ian Campbell wrote:
>>> On Tue, 2015-03-24 at 16:47 +0800, Chen, Tiejun wrote:
>>>> All guys,
>>>>
>>
>> Thanks for your reply.
>>
>>>> Sorry to bother you.
>>>>
>>>> I have a question to two files, tools/python/xen/lowlevel/xc/xc.c and
>>>> tools/python/xen/lowlevel/xl/xl.c. Who is a caller to those methods like
>>>> pyxc_methods[] and pyxl_methods[]?
>>>
>>> They are registered with the Python runtime, so they are called from
>>> Python code. The first member of the struct is the pythonic function
>>
>> Sorry I don't understanding this. So seems you mean instead of xl, this
>> is called by the third party user with python?
>
> Yes, tools/python/xen is the python bindings for various C libraries
> supported by Xen.

Thanks for your explanation.

>
> NB, the libxl ones are broken and not even compiled right now, you can
> ignore them.

Looks this is still compiled now.

>
>>
>>> name, e.g. from xc.c:
>>>       { "domain_create",
>>
>> Otherwise, often we always perform `xl create xxx' to create a VM. So I
>> think this should go into this flow like this,
>>
>> xl_cmdtable.c:main_create()
>> 	|
>> 	+ create_domain()
>> 		|
>> 		+ libxl_domain_create_new()
>> 			|
>> 			+ do_domain_create()
>> 				|
>> 				+ ....
>> Right?
>
> Yes, xl is written in C not python so tools/python doesn't enter the
> picture.

Yeah.

>
>>
>>>         (PyCFunction)pyxc_domain_create,
>>
>> So I don't see 'pyxc_domain_create' is called. Or I'm missing something...
>
> Chances are that there are no intree users of this code any more, xend
> would have used it at one time with something like:
> 	import xen.lowlevel.xc
>          xc = xen.lowlevel.xc.xc()
>          xc.domain_create()
> etc.
>
>>>
>>>> In my specific case, I'm trying to introduce a new flag to each a device
>>>> while assigning device. So this means I have to add a parameter, 'flag',
>>>> into
>>>>
>>>> int xc_assign_device(
>>>>        xc_interface *xch,
>>>>        uint32_t domid,
>>>>        uint32_t machine_sbdf)
>>>>
>>>> Then this is extended as
>>>>
>>>> int xc_assign_device(
>>>>        xc_interface *xch,
>>>>        uint32_t domid,
>>>>        uint32_t machine_sbdf,
>>>>        uint32_t flag)
>>>>
>>>> After this introduction, obviously I should cover all cases using
>>>> xc_assign_device(). And also I found this fallout goes into these two
>>>> files. For example, here pyxc_assign_device() is involved. Currently it
>>>> has two parameters, 'dom' and 'pci_str', and as I understand 'pci_str'
>>>> should represent all pci devices with SBDF format, right?
>>>
>>> It appears so, yes.
>>>
>>>> But I don't know exactly what rule should be complied to construct this
>>>> sort of flag into 'pci_str', or any reasonable idea to achieve my goal?
>>>
>>> If it is non-trivial to fix them IMHO it is acceptable for the new
>>> parameter to not be plumbed up to the Python bindings until someone
>>> comes along with a requirement to use it from Python. IOW you can just
>>> pass whatever the nop value is for the new argument.
>>>
>>
>> Should I extend this 'pci_str' like "Seg,bus,device,function:flag"? But
>> I'm not sure if I'm breaking the existing usage since like I said, I
>> don't know what scenarios are using these methods.
>
> Like I said in the paragraph above, if it is complicated then it is fine
> to ignore this new parameter from Python.
>
> I don't know what the semantics of flag is, if it is per SBDF then I

Yes, this should be a flag specific to a SBDF.

You know, I'm working to fix RMRR completely. Based on some discussion 
about that design ( I assume you may read that thread previously :) ), 
now we probably need to pass a flag to introduce our policy.

> suppose if you really wanted to expose this here then you would need to
> invent some syntax for doing so.
>

Definitely.

When I finish this I will send you to review technically.

Again, really appreciate your clarification to me.

Thanks
Tiejun