[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v5 06/10] IOMMU/MMU: propagate IOMMU Device-TLB flush error up to iommu_iotlb_flush{, _all} (top level ones).



>>> On 24.05.16 at 03:16, <quan.xu@xxxxxxxxx> wrote:
> On May 24, 2016 12:06 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>> >>> On 18.05.16 at 10:08, <quan.xu@xxxxxxxxx> wrote:
>> > --- a/xen/common/memory.c
>> > +++ b/xen/common/memory.c
>> > @@ -633,9 +633,9 @@ static long
>> memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t)
>> arg)
>> >      return rc;
>> >  }
>> >
>> > -static int xenmem_add_to_physmap(struct domain *d,
>> > -                                 struct xen_add_to_physmap *xatp,
>> > -                                 unsigned int start)
>> > +static int __must_check xenmem_add_to_physmap(struct domain *d,
>> > +                                              struct xen_add_to_physmap 
> *xatp,
>> > +                                              unsigned int start)
>> >  {
>> 
>> As before - either you do this adding of annotations completely, or you stop 
> at
>> the IOMMU / MM boundary. 
> 
> I prefer to stop at the IOMMU / MM boundary. The IOMMU boundary is obvious, 
> but what's the definition of MM boundary? I thought this is at MM boundary.

Not sure what you mean to understand. The IOMMU / MM boundary
is the boundary between those two components, there's no talk of
two boundaries here, and hence the question is unclear to me.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.