> -----Original Message----- > From: Jan Beulich <jbeul...@suse.com> > Sent: 21 September 2020 10:41 > To: p...@xen.org > Cc: 'Ian Jackson' <i...@xenproject.org>; 'Debian folks: Michael Tokarev' > <m...@tls.msk.ru>; 'Hans van > Kranenburg' <h...@knorrie.org>; 'Xen upstream folks with an interest: Andrew > Cooper' > <andrew.coop...@citrix.com>; 'Roger Pau Monné' <roger....@citrix.com>; > pkg-xen- > de...@lists.alioth.debian.org; xen-devel@lists.xenproject.org; 'My Xen > upstream tools co-maintainer: > Wei Liu' <w...@xen.org> > Subject: Re: qemu and Xen ABI-unstable libs > > On 21.09.2020 09:36, Paul Durrant wrote: > >> From: Xen-devel <xen-devel-boun...@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
