From: Auger Eric <eric.auger@redhat.com>
To: Andrew Jones <drjones@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:24:37 +0200 [thread overview]
Message-ID: <6a939f4b-f1b4-ff59-b074-aebb1b4e046a@redhat.com> (raw)
In-Reply-To: <20200330101955.2rlksuzkkvopk52t@kamzik.brq.redhat.com>
Hi Drew,
On 3/30/20 12:19 PM, Andrew Jones wrote:
> 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.
OK. Well I don't know if it is worth the candle. I will review the code
again and fix the remaining inconsistencies I can see.
Thanks
Eric
>
> 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
>>>>>
>>>>
>>>>
>>
>>
next prev parent reply other threads:[~2020-03-30 10:26 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
2020-03-30 10:24 ` Auger Eric [this message]
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=6a939f4b-f1b4-ff59-b074-aebb1b4e046a@redhat.com \
--to=eric.auger@redhat.com \
--cc=alexandru.elisei@arm.com \
--cc=andre.przywara@arm.com \
--cc=drjones@redhat.com \
--cc=eric.auger.pro@gmail.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).