[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] One question to lowlevel/xl/xl.c and lowlevel/xc/xc.c
From: |
Ian Campbell |
Subject: |
Re: [Qemu-devel] One question to lowlevel/xl/xl.c and lowlevel/xc/xc.c |
Date: |
Tue, 24 Mar 2015 10:20:44 +0000 |
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.
NB, the libxl ones are broken and not even compiled right now, you can
ignore them.
>
> > 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.
>
> > (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
suppose if you really wanted to expose this here then you would need to
invent some syntax for doing so.
Ian.
- [Qemu-devel] [v3][PATCH 0/2] libxl: try to support IGD passthrough for qemu upstream, Tiejun Chen, 2015/03/22
- [Qemu-devel] [v3][PATCH 1/2] libxl: introduce libxl__is_igd_vga_passthru, Tiejun Chen, 2015/03/22
- [Qemu-devel] [v3][PATCH 2/2] libxl: introduce gfx_passthru_kind, Tiejun Chen, 2015/03/22
- [Qemu-devel] One question to lowlevel/xl/xl.c and lowlevel/xc/xc.c, Chen, Tiejun, 2015/03/24
- Re: [Qemu-devel] One question to lowlevel/xl/xl.c and lowlevel/xc/xc.c, Ian Campbell, 2015/03/24
- Re: [Qemu-devel] One question to lowlevel/xl/xl.c and lowlevel/xc/xc.c, Chen, Tiejun, 2015/03/24
- Re: [Qemu-devel] One question to lowlevel/xl/xl.c and lowlevel/xc/xc.c,
Ian Campbell <=
- Re: [Qemu-devel] One question to lowlevel/xl/xl.c and lowlevel/xc/xc.c, Chen, Tiejun, 2015/03/24
- Re: [Qemu-devel] One question to lowlevel/xl/xl.c and lowlevel/xc/xc.c, Ian Campbell, 2015/03/24
- Re: [Qemu-devel] One question to lowlevel/xl/xl.c and lowlevel/xc/xc.c, Chen, Tiejun, 2015/03/24
- Re: [Qemu-devel] One question to lowlevel/xl/xl.c and lowlevel/xc/xc.c, Ian Campbell, 2015/03/25
- Re: [Qemu-devel] One question to lowlevel/xl/xl.c and lowlevel/xc/xc.c, Chen, Tiejun, 2015/03/25
Re: [Qemu-devel] [v3][PATCH 2/2] libxl: introduce gfx_passthru_kind, Ian Campbell, 2015/03/24
- Re: [Qemu-devel] [v3][PATCH 2/2] libxl: introduce gfx_passthru_kind, Chen, Tiejun, 2015/03/24
- Re: [Qemu-devel] [v3][PATCH 2/2] libxl: introduce gfx_passthru_kind, Ian Campbell, 2015/03/25
- Re: [Qemu-devel] [v3][PATCH 2/2] libxl: introduce gfx_passthru_kind, Chen, Tiejun, 2015/03/25
- Re: [Qemu-devel] [v3][PATCH 2/2] libxl: introduce gfx_passthru_kind, Ian Campbell, 2015/03/26