[Pkg-xen-devel] qemu and Xen ABI-unstable libs

[Paul Durrant]

> -----Original Message-----
> From: Jan Beulich <jbeulich at suse.com>
> Sent: 21 September 2020 10:41
> To: paul at xen.org
> Cc: 'Ian Jackson' <iwj at xenproject.org>; 'Debian folks: Michael Tokarev' <mjt at tls.msk.ru>; 'Hans van
> Kranenburg' <hans at knorrie.org>; 'Xen upstream folks with an interest: Andrew Cooper'
> <Andrew.Cooper3 at citrix.com>; 'Roger Pau Monné' <roger.pau at citrix.com>; pkg-xen-
> devel at lists.alioth.debian.org; xen-devel at lists.xenproject.org; 'My Xen upstream tools co-maintainer:
> Wei Liu' <wl at xen.org>
> Subject: Re: qemu and Xen ABI-unstable libs
> 
> On 21.09.2020 09:36, Paul Durrant wrote:
> >> From: Xen-devel <xen-devel-bounces at lists.xenproject.org> On Behalf Of Ian Jackson
> >> Sent: 18 September 2020 17:39
> >>
> >> xc_domain_iomem_permission
> >> xc_domain_populate_physmap_exact
> >> xc_domain_ioport_mapping
> >> xc_domain_memory_mapping
> >>
> >> The things done by these calls in qemu should be done by the Xen
> >> toolstack (libxl), during domain creation etc., instead.
> >
> > I don't think that is practical. E.g. if a guest re-programs a PCI I/O BAR then it may necessitate
> re-calling
> > xc_domain_ioport_mapping(); the tool-stack cannot know a priori where PCI BARs will end up in guest
> port/memory space.
> 
> In your reply I assume you meant just the latter two of the four?
> For these I agree, and as a result they shouldn't be domctl in
> the new model.
> 

Sorry if I wasn't clear. Yes, the latter two are what I was referring to.

  Paul

> Jan