Re: [Xen-devel] [PATCH v3 5/6] ioreq-server: add support for multiple servers

[George Dunlap <dunlapg@xxxxxxxxx>]

On Fri, Mar 14, 2014 at 11:52 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Wed, 2014-03-05 at 14:48 +0000, Paul Durrant wrote:
>> The legacy 'catch-all' server is always created with id 0. Secondary
>> servers will have an id ranging from 1 to a limit set by the toolstack
>> via the 'max_emulators' build info field. This defaults to 1 so ordinarily
>> no extra special pages are reserved for secondary emulators. It may be
>> increased using the secondary_device_emulators parameter in xl.cfg(5).
>> There's no clear limit to apply to the number of emulators so I've not
>> applied one.
>>
>> Because of the re-arrangement of the special pages in a previous patch we
>> only need the addition of parameter HVM_PARAM_NR_IOREQ_SERVERS to determine
>> the layout of the shared pages for multiple emulators. Guests migrated in
>> from hosts without this patch will be lacking the save record which stores
>> the new parameter and so the guest is assumed to only have had a single
>> emulator.
>>
>> Added some more emacs boilerplate to xenctrl.h and xenguest.h
>>
>> Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
>> ---
>>  docs/man/xl.cfg.pod.5            |    7 +
>>  tools/libxc/xc_domain.c          |  175 +++++++
>>  tools/libxc/xc_domain_restore.c  |   20 +
>>  tools/libxc/xc_domain_save.c     |   12 +
>>  tools/libxc/xc_hvm_build_x86.c   |   24 +-
>>  tools/libxc/xenctrl.h            |   51 ++
>>  tools/libxc/xenguest.h           |   12 +
>>  tools/libxc/xg_save_restore.h    |    1 +
>>  tools/libxl/libxl.h              |    8 +
>>  tools/libxl/libxl_create.c       |    3 +
>>  tools/libxl/libxl_dom.c          |    1 +
>>  tools/libxl/libxl_types.idl      |    1 +
>>  tools/libxl/xl_cmdimpl.c         |    3 +
>>  xen/arch/x86/hvm/hvm.c           |  964 
>> ++++++++++++++++++++++++++++++++++++--
>>  xen/arch/x86/hvm/io.c            |    2 +-
>>  xen/include/asm-x86/hvm/domain.h |   23 +-
>>  xen/include/asm-x86/hvm/hvm.h    |    3 +-
>>  xen/include/asm-x86/hvm/io.h     |    2 +-
>>  xen/include/public/hvm/hvm_op.h  |   70 +++
>>  xen/include/public/hvm/ioreq.h   |    1 +
>>  xen/include/public/hvm/params.h  |    4 +-
>>  21 files changed, 1324 insertions(+), 63 deletions(-)
>>
>> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
>> index e15a49f..0226c55 100644
>> --- a/docs/man/xl.cfg.pod.5
>> +++ b/docs/man/xl.cfg.pod.5
>> @@ -1281,6 +1281,13 @@ specified, enabling the use of XenServer PV drivers 
>> in the guest.
>>  This parameter only takes effect when device_model_version=qemu-xen.
>>  See F<docs/misc/pci-device-reservations.txt> for more information.
>>
>> +=item B<secondary_device_emulators=NUMBER>
>> +
>> +If a number of secondary device emulators (i.e. in addition to
>> +qemu-xen or qemu-xen-traditional) are to be invoked to support the
>> +guest then this parameter can be set with the count of how many are
>> +to be used. The default value is zero.
>
> This is an odd thing to expose to the user. Surely (lib)xl should be
> launching these things while building the domain and therefore know how
> many there are the config options should be things like
> "use_split_dm_for_foo=1" or device_emulators = ["/usr/bin/first-dm",
> "/usr/local/bin/second-dm"] or something.

I think the idea was that someone may want to hot-plug such an
emulated device later.

I agree that long-term, the standard should be to specify secondary
device models in the config file and have libxl / xl figure out how
many there are.  But I don't think that means that having a way to
specify it explicitly is a bad idea; and I think for development
purposes it might make sense to start with it manually specified and
add the support for multiple emulators in the config file later.

[snip]

>>          xc_set_hvm_param(xch, dom, HVM_PARAM_ACPI_IOPORTS_LOCATION, 1);
>> diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
>> index 42c4752..3293e29 100644
>> --- a/tools/libxc/xc_domain_save.c
>> +++ b/tools/libxc/xc_domain_save.c
>> @@ -1731,6 +1731,18 @@ int xc_domain_save(xc_interface *xch, int io_fd, 
>> uint32_t dom, uint32_t max_iter
>>              PERROR("Error when writing the viridian flag");
>>              goto out;
>>          }
>> +
>> +        chunk.id = XC_SAVE_ID_HVM_NR_IOREQ_SERVERS;
>> +        chunk.data = 0;
>> +        xc_get_hvm_param(xch, dom, HVM_PARAM_NR_IOREQ_SERVERS,
>> +                         (unsigned long *)&chunk.data);
>> +
>> +        if ( (chunk.data != 0) &&
>
> Can this ever be 0 for an HVM guest?

If we end up making PVH basically a degenerate case of HVM (without a
device model), then something like this may.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel