RE: qemu and Xen ABI-unstable libs

[Paul Durrant <xadimgnik@xxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: 21 September 2020 10:41
> To: paul@xxxxxxx
> Cc: 'Ian Jackson' <iwj@xxxxxxxxxxxxxx>; 'Debian folks: Michael Tokarev' 
> <mjt@xxxxxxxxxx>; 'Hans van
> Kranenburg' <hans@xxxxxxxxxxx>; 'Xen upstream folks with an interest: Andrew 
> Cooper'
> <Andrew.Cooper3@xxxxxxxxxx>; 'Roger Pau Monné' <roger.pau@xxxxxxxxxx>; 
> pkg-xen-
> devel@xxxxxxxxxxxxxxxxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxxx; 'My Xen 
> upstream tools co-maintainer:
> Wei Liu' <wl@xxxxxxx>
> Subject: Re: qemu and Xen ABI-unstable libs
> 
> On 21.09.2020 09:36, Paul Durrant wrote:
> >> From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> 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