Re: [PATCH v3 3/9] xen/mm: move modify_identity_mmio to global file and drop __init

["Jan Beulich" <JBeulich@suse.com>]

>>> On 21.06.17 at 14:43, <roger.pau@citrix.com> wrote:
> On Wed, Jun 21, 2017 at 05:57:19AM -0600, Jan Beulich wrote:
>> >>> On 21.06.17 at 13:11, <roger.pau@citrix.com> wrote:
>> > On Fri, May 19, 2017 at 07:35:39AM -0600, Jan Beulich wrote:
>> >> >>> On 27.04.17 at 16:35, <roger.pau@citrix.com> wrote:
>> >> > +int modify_mmio(struct domain *d, gfn_t gfn, mfn_t mfn, unsigned long 
> nr_pages,
>> >> > +                const bool map)
>> >> > +{
>> >> > +    int rc;
>> >> > +
>> >> > +    /*
>> >> > +     * Make sure this function is only used by the hardware domain, 
> because it
>> >> > +     * can take an arbitrary long time, and could DoS the whole system.
>> >> > +     */
>> >> > +    ASSERT(is_hardware_domain(d));
>> >> 
>> >> If that can happen arbitrarily at run time (rather than just at boot,
>> >> as suggested by the removal of __init), it definitely can't remain as
>> >> is and will instead need to make use of continuations. I'm therefore
>> >> unconvinced you really want to move this code instead of simply
>> >> calling {,un}map_mmio_regions() while taking care of preemption
>> >> needs.
>> > 
>> > I'm not sure I know how to use continuations with non-hypercall
>> > vmexits. Do you have any recommendations about how to do this? pause
>> > the domain and run the mmio changes inside of a tasklet?
>> 
>> That would be one option. Or you could derive from the approach
>> used for waiting for a response from the device model.
> 
> AFAICT the ioreq code pauses the domain and waits for a reply from the
> dm, but in that case I would still need the tasklet in order to perform
> the work (since there's no dm here).

Well, that's kind of pausing (it's not an explicit domain_pause(),
and you really would mean to pause just the vCPU here). Otoh
to prevent hangs we simply call process_pending_softirqs()
every once in a while in a few other cases, so maybe doing that
would already suffice here.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel