[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] One question to lowlevel/xl/xl.c and lowlevel/xc/xc.c
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
