On March 24, 2016 5:59pm, <jbeul...@suse.com> wrote:
> >>> On 24.03.16 at 10:02, <quan...@intel.com> wrote:
> > On March 18, 2016 5:49pm, <jbeul...@suse.com> wrote:


> >    3. For iommu_{,un}map_page(), we'd better fix it as a normal error,
> > as the error is not only from iommu flush, .e.g, '-ENOMEM'.
> >      So, we need to {,un}map from the IOMMU, return an error, and roll
> > back the failed operation( .e.g, unmap EPT).
> 
> Well, if that possible in a provably correct way, then sure. But be clear - 
> when
> the failure occurs while unmapping, unmapping the EPT entry obviously can't be
> the solution, 

I hope we discuss about the same point as bellow?:
   ept_set_entry()
   {
    ....
          if ( iommu_flags )
                for ( i = 0; i < (1 << order); i++ )
                    iommu_map_page(d, gfn + i, mfn_x(mfn) + i, iommu_flags);
            else
                for ( i = 0; i < (1 << order); i++ )
                    iommu_unmap_page(d, gfn + i);
    ....
   }


> you'd need a true roll back.

Does it refer to as:
If the old entry is present, we need to write back the old entry? 

> And of course you should keep in mind
> what happens to the guest if such an operation fails: If you can be certain 
> it'll
> crash because of this later on anyway, you're likely better off crashing it 
> right
> away (such that the reason for the crash is at least obvious).
> 

I think, for iommu_{,un}map_page(), it would be not aware that the domain is 
going to crash.
As mentioned,  the error is not only from iommu flush.
We need to fix it one by one. fortunately, it is limited.




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

Reply via email to