kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Alexander Gordeev <agordeev@redhat.com>
Cc: kvm@vger.kernel.org, drjones@redhat.com, jan.kiszka@web.de,
	rkrcmar@redhat.com, pbonzini@redhat.com
Subject: Re: [PATCH v7 12/14] x86: intel-iommu: add dmar test
Date: Wed, 7 Dec 2016 13:09:13 +0800	[thread overview]
Message-ID: <20161207050913.GD3469@pxdev.xzpeter.org> (raw)
In-Reply-To: <20161205093205.GA22576@agordeev.lab.eng.brq.redhat.com>

On Mon, Dec 05, 2016 at 10:32:06AM +0100, Alexander Gordeev wrote:

[...]

> > +static void vtd_install_pte(vtd_pte_t *root, iova_t iova,
> > +			    phys_addr_t pa, int level_target)
> > +{
> > +	int level;
> > +	unsigned int offset;
> > +	void *page;
> > +
> > +	for (level = VTD_PAGE_LEVEL; level > level_target; level--) {
> > +		offset = PGDIR_OFFSET(iova, level);
> > +		if (!(root[offset] & VTD_PTE_RW)) {
> > +			page = alloc_page();
> > +			memset(page, 0, PAGE_SIZE);
> > +			root[offset] = virt_to_phys(page) | VTD_PTE_RW;
> > +		}
> > +		root = (uint64_t *)(root[offset] & VTD_PTE_ADDR);
> 
> Physical to virtual translation is missed.

Exactly. Thanks. :)

> Also, PAGE_SHIFT implied instead of VTD_PAGE_SHIFT (see below).
> 
> > +	}
> > +
> > +	offset = PGDIR_OFFSET(iova, level);
> > +	root[offset] = pa | VTD_PTE_RW;
> > +	if (level != 1) {
> > +		/* This is huge page */
> > +		root[offset] |= VTD_PTE_HUGE;
> > +	}
> > +}
> > +
> > +#define  VTD_FETCH_VIRT_ADDR(x) \
> > +	((void *)(((uint64_t)phys_to_virt(x)) >> PAGE_SHIFT))
> 
> Just a nit. A fetch somehow implies pulling data, while here
> we have a translation. What about VTD_PHYS_TO_VIRT?

Sure. Will rename.

[...]

> > +	if (!ce->present) {
> > +		slptptr = alloc_page();
> > +		memset(slptptr, 0, PAGE_SIZE);
> > +		memset(ce, 0, sizeof(*ce));
> > +		/* To make it simple, domain ID is the same as SID */
> > +		ce->domain_id = sid;
> > +		/* We only test 39 bits width case (3-level paging) */
> > +		ce->addr_width = VTD_CE_AW_39BIT;
> > +		ce->slptptr = virt_to_phys(slptptr) >> PAGE_SHIFT;
> 
> It seems left shift is needed here, not the right one.

I still think the right shift is what we want.

Here ce->slptptr is a bitfield. It stores the bits HAW:12 (maximum is
63:12) of second level page table pointer address, so I need a right
shift, no?

> 
> Also, using PAGE_SHIFT (and possible other memory constants throughout
> the source) looks wrong to me. Instead it should be VTD_PAGE_SHIFT (and
> alike) - no matter they are equal to the memory constants at the moment.

Hmm sure. I can define one for vt-d.

[...]

> > +#define VTD_PTE_R                   (1 << 0)
> > +#define VTD_PTE_W                   (1 << 1)
> > +#define VTD_PTE_RW                  (VTD_PTE_R | VTD_PTE_W)
> > +#define VTD_PTE_ADDR                GENMASK_ULL(51, 12)
> 
> Are we safe to include 51:HAW lines? They are marked as Reserved
> and we might write 1s to these bits occasionally. I do not really
> believe it could cause trouble ever - just need some clarity here.

Actually here I *guess* what I wanted was:

  GENMASK_ULL(63, 12)

Luckily 51 is enough for us (because currently we only support 3 level
page table, this will work as long as this number is bigger than 39).
However I think I should use 63 here...

Regarding to the reserved bits you mentioned - IMO it's okay to
include them since the reserved bits should be set to zero by guest
software.

Thanks,

-- peterx

  reply	other threads:[~2016-12-07  5:10 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-29  4:25 [PATCH v7 00/14] VT-d unit test Peter Xu
2016-11-29  4:25 ` [PATCH v7 01/14] pci: fix missing extern for pci_testdev() Peter Xu
2016-11-29  4:25 ` [PATCH v7 02/14] x86/asm: add cpu_relax() Peter Xu
2016-11-29  4:25 ` [PATCH v7 03/14] libcflat: introduce is_power_of_2() Peter Xu
2016-11-29  4:25 ` [PATCH v7 04/14] x86: intel-iommu: add vt-d init test Peter Xu
2016-12-01 13:14   ` Alexander Gordeev
2016-12-01 19:37     ` Alexander Gordeev
2016-12-02  3:12     ` Peter Xu
2016-12-02  7:50       ` Alexander Gordeev
2016-12-05  2:31         ` Peter Xu
2016-11-29  4:25 ` [PATCH v7 05/14] libcflat: add IS_ALIGNED() macro, and page sizes Peter Xu
2016-11-29  4:25 ` [PATCH v7 06/14] libcflat: moving MIN/MAX here Peter Xu
2016-11-29  4:25 ` [PATCH v7 07/14] vm/page: provide PGDIR_OFFSET() macro Peter Xu
2016-11-29  4:25 ` [PATCH v7 08/14] pci: introduce struct pci_dev Peter Xu
2016-11-29  4:25 ` [PATCH v7 09/14] pci: provide pci_scan_bars() Peter Xu
2016-11-29  4:25 ` [PATCH v7 10/14] pci: provide pci_enable_defaults() Peter Xu
2016-11-29  4:25 ` [PATCH v7 11/14] pci: edu: introduce pci-edu helpers Peter Xu
2016-11-29  4:25 ` [PATCH v7 12/14] x86: intel-iommu: add dmar test Peter Xu
2016-12-05  9:32   ` Alexander Gordeev
2016-12-07  5:09     ` Peter Xu [this message]
2016-11-29  4:25 ` [PATCH v7 13/14] pci: add msi support for 32/64bit address Peter Xu
2016-11-29  4:25 ` [PATCH v7 14/14] x86: intel-iommu: add IR MSI test Peter Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161207050913.GD3469@pxdev.xzpeter.org \
    --to=peterx@redhat.com \
    --cc=agordeev@redhat.com \
    --cc=drjones@redhat.com \
    --cc=jan.kiszka@web.de \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).