Re: [RFC PATCH V1 04/12] xen/arm: Introduce arch specific bits for IOREQ/DM features

[Oleksandr <olekstysh@xxxxxxxxx>]

On 05.08.20 12:32, Julien Grall wrote:

Hi Julien, Stefano

> > > diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> > > index 5fdb6e8..5823f11 100644
> > > --- a/xen/include/asm-arm/p2m.h
> > > +++ b/xen/include/asm-arm/p2m.h
> > > @@ -385,10 +385,11 @@ static inline int set_foreign_p2m_entry(struct 
> > > domain *d, unsigned long gfn,
> > >                                           mfn_t mfn)
> > >   {
> > >       /*
> > > -     * NOTE: If this is implemented then proper reference counting of
> > > -     *       foreign entries will need to be implemented.
> > > +     * XXX: handle properly reference. It looks like the page may 
> > > not always
> > > +     * belong to d.
> > Just as a reference, and without taking away anything from the comment,
> > I think that QEMU is doing its own internal reference counting for these
> > mappings.
> I am not sure how this matters here? We can't really trust the DM to 
> do the right thing if it is not running in dom0.
> But, IIRC, the problem is some of the pages doesn't belong to do a 
> domain, so it is not possible to treat them as foreign mapping (e.g. 
> you wouldn't be able to grab a reference). This investigation was done 
> a couple of years ago, so this may have changed in recent Xen.
Well, emulator is going to be used in driver domain, so this TODO must 
be resolved. I suspect that the check for a hardware domain in 
acquire_resource() which I skipped in a hackish way [1] could be simply 
removed once proper reference counting is implemented in Xen, correct?
Could you please provide some pointers on that problem? Maybe some 
questions need to be investigated again? Unfortunately, it is not 
completely clear to me the direction to follow...
***
I am wondering whether the similar problem exists on x86 as well? The 
FIXME tag (before checking for a hardware domain in acquire_resource()) 
in the common code makes me think it is a common issue. From other side 
x86's
implementation of set_foreign_p2m_entry() is exists unlike Arm's one 
(which returned -EOPNOTSUPP so far). Or these are unrelated?
***

[1] https://lists.xen.org/archives/html/xen-devel/2020-08/msg00075.html



--
Regards,

Oleksandr Tyshchenko