Re: [Qemu-devel] [PATCH v3 1/2] intel-iommu: differentiate host address width from IOVA address width.

[Yu Zhang <yu.c.zhang@linux.intel.com>]

On Fri, Dec 21, 2018 at 02:02:28PM -0500, Michael S. Tsirkin wrote:
> On Sat, Dec 22, 2018 at 01:37:58AM +0800, Yu Zhang wrote:
> > On Fri, Dec 21, 2018 at 12:04:49PM -0500, Michael S. Tsirkin wrote:
> > > On Sat, Dec 22, 2018 at 12:09:44AM +0800, Yu Zhang wrote:
> > > > Well, my understanding of the vt-d spec is that the address limitation in
> > > > DMAR are referring to the same concept of CPUID.MAXPHYSADDR. I do not think
> > > > there's any different in the native scenario. :)
> > > 
> > > I think native machines exist on which the two values are different.
> > > Is that true?
> > 
> > I think the answer is not. My understanding is that HAW(host address wdith) is
> > the maximum physical address width a CPU can detects(by cpuid.0x80000008).
> > 
> > I agree there are some addresses the CPU does not touch, but they are still in
> > the physical address space, and there's only one physical address space...
> > 
> > B.R.
> > Yu
> 
> Ouch I thought we are talking about the virtual address size.
> I think I did have a box where VTD's virtual address size was
> smaller than CPU's.
> For physical one - we just need to make it as big as max supported
> memory right?

Well, my understanding of the physical one is the maximum physical address
width. Sorry, this explain seems nonsense... I mean, it's not just about
the max supported memory, but also covers MMIO. It shall be detectable
from cpuid, or ACPI's DMAR table, instead of calculated by the max memory
size. One common usage of this value is to tell the paging structure entries(
CPU's or IOMMU's) which bits shall be reserved. There are also some registers
e.g. apic base reg etc, whose contents are physical addresses, therefore also
need to follow the similar requirement for the reserved bits.

So I think the correct direction might be to define this property in the
machine status level, instead of the CPU level. Is this reasonable to you?

> 
> -- 
> MST

B.R.
Yu