qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Jones <drjones@redhat.com>
To: Auger Eric <eric.auger@redhat.com>
Cc: peter.maydell@linaro.org, thuth@redhat.com, kvm@vger.kernel.org,
	maz@kernel.org, qemu-devel@nongnu.org, qemu-arm@nongnu.org,
	andre.przywara@arm.com, Zenghui Yu <yuzenghui@huawei.com>,
	alexandru.elisei@arm.com, kvmarm@lists.cs.columbia.edu,
	eric.auger.pro@gmail.com
Subject: Re: [kvm-unit-tests PATCH v7 06/13] arm/arm64: ITS: Introspection tests
Date: Mon, 30 Mar 2020 12:19:55 +0200	[thread overview]
Message-ID: <20200330101955.2rlksuzkkvopk52t@kamzik.brq.redhat.com> (raw)
In-Reply-To: <7d6dc4e7-82b4-3c54-574f-2149d4a85c48@redhat.com>

On Mon, Mar 30, 2020 at 11:56:00AM +0200, Auger Eric wrote:
> Hi,
> 
> On 3/30/20 11:11 AM, Andrew Jones wrote:
> > On Mon, Mar 30, 2020 at 10:46:57AM +0200, Auger Eric wrote:
> >> Hi Zenghui,
> >>
> >> On 3/30/20 10:30 AM, Zenghui Yu wrote:
> >>> Hi Eric,
> >>>
> >>> On 2020/3/20 17:24, Eric Auger wrote:
> >>>> +static void its_cmd_queue_init(void)
> >>>> +{
> >>>> +    unsigned long order = get_order(SZ_64K >> PAGE_SHIFT);
> >>>> +    u64 cbaser;
> >>>> +
> >>>> +    its_data.cmd_base = (void *)virt_to_phys(alloc_pages(order));
> >>>
> >>> Shouldn't the cmd_base (and the cmd_write) be set as a GVA?
> >> yes it should
> > 
> > If it's supposed to be a virtual address, when why do the virt_to_phys?
> What is programmed in CBASER register is a physical address. So the
> virt_to_phys() is relevant. The inconsistency is in its_allocate_entry()
> introduced later on where I return the physical address instead of the
> virtual address. I will fix that.
> 
> 
> > 
> >>>
> >>> Otherwise I think we will end-up with memory corruption when writing
> >>> the command queue.  But it seems that everything just works fine ...
> >>> So I'm really confused here :-/
> >> I was told by Paolo that the VA/PA memory map is flat in kvmunit test.
> > 
> > What does flat mean?
> 
> Yes I meant an identity map.
> 
>  kvm-unit-tests, at least arm/arm64, does prepare
> > an identity map of all physical memory, which explains why the above
> > is working.
> 
> should be the same on x86

Maybe, but I didn't write or review how x86 does their default map, so I
don't know.

> 
>  It's doing virt_to_phys(some-virt-addr), which gets a
> > phys addr, but when the ITS uses it as a virt addr it works because
> > we *also* have a virt addr == phys addr mapping in the default page
> > table, which is named "idmap" for good reason.
> > 
> > I think it would be better to test with the non-identity mapped addresses
> > though.
> 
> is there any way to exercise a non idmap?

You could create your own map and then switch to it. See lib/arm/asm/mmu-api.h

But, you don't have to switch the whole map to use non-identity mapped
addresses. Just create new virt mappings to the phys addresses you're
interested in, and then use those new virt addresses instead. If you're
worried that somewhere an identity mapped virt address is getting used
because of a phys/virt address mix up, then you could probably sprinkle
some assert(virt_to_phys(addr) != addr)'s around to ensure it.

Thanks,
drew

> 
> Thanks
> 
> Eric
> > 
> > Thanks,
> > drew
> > 
> >>
> >>>
> >>>> +
> >>>> +    cbaser = ((u64)its_data.cmd_base | (SZ_64K / SZ_4K - 1)    |
> >>>> GITS_CBASER_VALID);
> >>>> +
> >>>> +    writeq(cbaser, its_data.base + GITS_CBASER);
> >>>> +
> >>>> +    its_data.cmd_write = its_data.cmd_base;
> >>>> +    writeq(0, its_data.base + GITS_CWRITER);
> >>>> +}
> >>>
> >>> Otherwise this looks good,
> >>> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
> >> Thanks!
> >>
> >> Eric
> >>>
> >>>
> >>> Thanks
> >>>
> >>
> >>
> 
> 



  reply	other threads:[~2020-03-30 10:20 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-20  9:24 [kvm-unit-tests PATCH v7 00/13] arm/arm64: Add ITS tests Eric Auger
2020-03-20  9:24 ` [kvm-unit-tests PATCH v7 01/13] libcflat: Add other size defines Eric Auger
2020-03-20  9:24 ` [kvm-unit-tests PATCH v7 02/13] page_alloc: Introduce get_order() Eric Auger
2020-03-20  9:24 ` [kvm-unit-tests PATCH v7 03/13] arm/arm64: gic: Introduce setup_irq() helper Eric Auger
2020-03-20  9:24 ` [kvm-unit-tests PATCH v7 04/13] arm/arm64: gicv3: Add some re-distributor defines Eric Auger
2020-03-20  9:24 ` [kvm-unit-tests PATCH v7 05/13] arm/arm64: gicv3: Set the LPI config and pending tables Eric Auger
2020-03-20  9:24 ` [kvm-unit-tests PATCH v7 06/13] arm/arm64: ITS: Introspection tests Eric Auger
2020-03-30  8:30   ` Zenghui Yu
2020-03-30  8:46     ` Auger Eric
2020-03-30  9:11       ` Andrew Jones
2020-03-30  9:56         ` Auger Eric
2020-03-30 10:19           ` Andrew Jones [this message]
2020-03-30 10:24             ` Auger Eric
2020-03-30 12:20         ` Zenghui Yu
2020-03-20  9:24 ` [kvm-unit-tests PATCH v7 07/13] arm/arm64: ITS: its_enable_defaults Eric Auger
2020-03-20  9:24 ` [kvm-unit-tests PATCH v7 08/13] arm/arm64: ITS: Device and collection Initialization Eric Auger
2020-03-25  8:10   ` Zenghui Yu
2020-03-25 21:20     ` Auger Eric
2020-03-30  9:13       ` Andrew Jones
2020-03-20  9:24 ` [kvm-unit-tests PATCH v7 09/13] arm/arm64: ITS: Commands Eric Auger
2020-03-30  9:22   ` Zenghui Yu
2020-03-30  9:57     ` Auger Eric
2020-03-20  9:24 ` [kvm-unit-tests PATCH v7 10/13] arm/arm64: ITS: INT functional tests Eric Auger
2020-03-30 10:43   ` Zenghui Yu
2020-04-02  8:50     ` Auger Eric
2020-04-02 12:40       ` Zenghui Yu
2020-04-02 14:41         ` Andrew Jones
2020-03-20  9:24 ` [kvm-unit-tests PATCH v7 11/13] arm/run: Allow Migration tests Eric Auger
2020-03-20  9:24 ` [kvm-unit-tests PATCH v7 12/13] arm/arm64: ITS: migration tests Eric Auger
2020-03-30 10:55   ` Zenghui Yu
2020-03-20  9:24 ` [kvm-unit-tests PATCH v7 13/13] arm/arm64: ITS: pending table migration test Eric Auger
2020-03-30 12:06   ` Zenghui Yu
2020-03-30 12:38     ` Auger Eric
2020-03-30 13:17       ` Zenghui Yu

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=20200330101955.2rlksuzkkvopk52t@kamzik.brq.redhat.com \
    --to=drjones@redhat.com \
    --cc=alexandru.elisei@arm.com \
    --cc=andre.przywara@arm.com \
    --cc=eric.auger.pro@gmail.com \
    --cc=eric.auger@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=maz@kernel.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    --cc=yuzenghui@huawei.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).