[Top][All Lists]

[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: Chen, Tiejun
Subject: Re: [Qemu-devel] One question to lowlevel/xl/xl.c and lowlevel/xc/xc.c
Date: Tue, 24 Mar 2015 18:15:53 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

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?

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,

        + create_domain()
                + libxl_domain_create_new()
                        + do_domain_create()
                                + ....


So I don't see 'pyxc_domain_create' is called. Or I'm missing something...

       "Create a new domain.\n"
       " dom    [int, 0]:        Domain identifier to use (allocated if 
       "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.

If you can give a real case to call this, things couldn't be better :)

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',

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.


reply via email to

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