[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v12 5/6] x86/ioreq server: Asynchronously reset outstanding p2m_ioreq_server entries.
>>> On 07.04.17 at 12:55, <yu.c.zhang@xxxxxxxxxxxxxxx> wrote: > On 4/7/2017 6:26 PM, Jan Beulich wrote: >>>>> On 07.04.17 at 11:53, <yu.c.zhang@xxxxxxxxxxxxxxx> wrote: >>> On 4/7/2017 5:40 PM, Jan Beulich wrote: >>>>>>> On 06.04.17 at 17:53, <yu.c.zhang@xxxxxxxxxxxxxxx> wrote: >>>>> @@ -965,7 +987,7 @@ static mfn_t ept_get_entry(struct p2m_domain *p2m, >>>>> if ( is_epte_valid(ept_entry) ) >>>>> { >>>>> if ( (recalc || ept_entry->recalc) && >>>>> - p2m_is_changeable(ept_entry->sa_p2mt) ) >>>>> + p2m_check_changeable(ept_entry->sa_p2mt) ) >>>> I think the distinction between these two is rather arbitrary, and I >>>> also think this is part of the problem above: Distinguishing log-dirty >>>> from ram-rw requires auxiliary data to be consulted. The same >>>> ought to apply to ioreq-server, and then there wouldn't be a need >>>> to have two p2m_*_changeable() flavors. >>> Well, I think we have also discussed this quite long ago, here is the link. >>> https://lists.xen.org/archives/html/xen-devel/2016-09/msg01017.html >> That was a different discussion, namely not considering this ... >> >>>> Of course the subsequent use p2m_is_logdirty_range() may then >>>> need amending. >>>> >>>> In the end it looks like you have the inverse problem here compared >>>> to above: You should return ram-rw when the reset was already >>>> initiated. At least that's how I would see the logic to match up with >>>> the log-dirty handling (where the _effective_ rather than the last >>>> stored type is being returned). >> ... at all. > > Sorry I still do not get it. Leaving ioreq-server out of the picture, what the function returns to the caller is the type as it would be if a re-calculation would have been done on the entry, even if that hasn't happened yet (the function here shouldn't change any entries after all). I think we want the same behavior here for what have been ioreq-server entries (and which would become ram-rw after the next re-calc). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |