[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 09:51:44 +0000 |
On Tue, 2015-03-24 at 16:47 +0800, Chen, Tiejun wrote:
> All guys,
>
> 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
name, e.g. from xc.c:
{ "domain_create",
(PyCFunction)pyxc_domain_create,
METH_VARARGS | METH_KEYWORDS, "\n"
"Create a new domain.\n"
" dom [int, 0]: Domain identifier to use (allocated if zero).\n"
"Returns: [int] new domain identifier; -1 on error.\n" },
defines a method called domain_create, in the xen.lowlevel.xc namespace.
> And how should we call these approaches?
I'm not sure what you are asking here.
> 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.
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 <=
- 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/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