|
From: | Jason Wang |
Subject: | Re: [Qemu-devel] [PATCH RFC v3 13/14] intel_iommu: allow dynamic switch of IOMMU region |
Date: | Mon, 16 Jan 2017 16:01:00 +0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 |
On 2017年01月16日 15:50, Peter Xu wrote:
On Mon, Jan 16, 2017 at 02:20:31PM +0800, Jason Wang wrote: [...]diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c index fd75112..2596f11 100644 --- a/hw/i386/intel_iommu.c +++ b/hw/i386/intel_iommu.c @@ -1343,9 +1343,49 @@ static void vtd_handle_gcmd_sirtp(IntelIOMMUState *s) vtd_set_clear_mask_long(s, DMAR_GSTS_REG, 0, VTD_GSTS_IRTPS); } +static void vtd_switch_address_space(VTDAddressSpace *as, bool iommu_enabled)Looks like you can check s->dmar_enabled here?Yes, we need to check old state in case we don't need a switch at all. Actually I checked it...
I mean is there a chance that iommu_enabled( better name should be dmar_enabled) is not equal to s->dmar_enabled? Looks not.
vtd_handle_gcmd_te() did: ... if (en) { s->dmar_enabled = true; /* Ok - report back to driver */ vtd_set_clear_mask_long(s, DMAR_GSTS_REG, 0, VTD_GSTS_TES); } else { s->dmar_enabled = false; ...You can vtd_switch_address_space_all(s, en) after this which will call this function. And another caller like you've pointed out has already call this through s->dmar_enabled. So en here is always s->dmar_enalbed?
Thanks
[Prev in Thread] | Current Thread | [Next in Thread] |