[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/4 v2] x86/EPT: refine direct MMIO checking when determining EMT
>>> On 28.04.14 at 11:06, <kevin.tian@xxxxxxxxx> wrote: >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx] >> Sent: Monday, April 28, 2014 4:25 PM >> >> >>> On 28.04.14 at 09:59, <kevin.tian@xxxxxxxxx> wrote: >> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx] >> >> @@ -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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |