Re: [PATCH 2/4 v2] x86/EPT: refine direct MMIO checking when determining EMT

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

>>> On 28.04.14 at 11:06, <kevin.tian@intel.com> wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Monday, April 28, 2014 4:25 PM
>> 
>> >>> On 28.04.14 at 09:59, <kevin.tian@intel.com> wrote:
>> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> >> @@ -810,10 +811,7 @@ int epte_get_entry_emt(struct domain *d,
>> >>          return -1;
>> >>      }
>> >>
>> >> -    if ( !iommu_enabled ||
>> >> -         (rangeset_is_empty(d->iomem_caps) &&
>> >> -          rangeset_is_empty(d->arch.ioport_caps) &&
>> >> -          !has_arch_pdevs(d)) )
>> >> +    if ( !need_iommu(d) && !cache_flush_permitted(d) )
>> >
>> > &&->||
>> 
>> No, specifically not - we shouldn't force WB in either case.
>> 
> 
> well, I gave original comments with the impression that it's a cleanup patch
> instead of fixing anything, e.g. iommu_enabled->need_iommu, and open-coding
> to cache_flush_permitted. Based on that thought, && changes original meaning.
> 
> so you actually fix the conditions here. I didn't follow up latest advance 
> in device
> assignment recently. Could you elaborate in which situation I/O resources 
> are
> assigned while iommu is not required?

It's not so much a question of "required": IOMMU setup only
happens when a PCI device gets assigned to a guest. It specifically
does not happen (and would make no sense, because the IOMMU
concepts are PCI device based) when a raw MMIO or port range gets
assigned. While the latter is insecure, I don't think we currently do
anything to disallow this, and hence we shouldn't break it here.

Jan