xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Sergej Proskurin <proskurin@sec.in.tum.de>
To: Julien Grall <julien.grall@arm.com>, xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v4 8/9] arm/mem_access: Add short-descriptor based gpt
Date: Fri, 23 Jun 2017 21:09:15 +0200	[thread overview]
Message-ID: <d477979e-146a-62b7-86d5-a85f4779597d@sec.in.tum.de> (raw)
In-Reply-To: <dd0f8b2b-3072-f729-ddb7-ad2c969a7d5f@arm.com>

Hi Julien,

[...]

> 
> Looking at the code, I see very limited point of having the offsets
> array as you don't use a loop and also use each offset in a single place.
> 
>> +        ((paddr_t)(gva >> 20) & ((1ULL << (12 - n)) - 1)),
> 
Don't you think it is more readable to have the GVA offsets at one
place. Also, the functionality is in this way similar to the one shown
in guest_walk_ld. In my opinion, it is more intuitive to have both
functions work in a similar way. I suggest keeping the array, however
using GENMASK to generate it (as you mentioned in your comments below).

const vaddr_t offsets[2] = {
    (gva & GENMASK((31 - n), 20)) >> 20,
    (gva & GENMASK(19, 12)) >> 12,
};

> 
> Furthermore, it would be clearer if you first mask then shift. As it
> helps to understand the code.
> 
> If you use GENMASK (or GENMASK_ULL if you don't extend GENMASK), this
> will make everything more obvious:
> 

[...]


>> +
>> +    /*
>> +     * As we have considered up to 2 MSBs of the GVA for mapping the
>> first
>> +     * level translation table, we need to make sure that we limit
>> the table
>> +     * offset that is is indexed by GVA<31-n:20> to max 10 bits to avoid
>> +     * exceeding the page size limit.
>> +     */
>> +    mask = ((1ULL << 10) - 1);
>> +    pte = table[offsets[level] & mask];
> 
> This looks quite complex for just reading a pte. I think it would be
> worth to leverage the vgic_guest_access_memory for that (same in LPAE).
> It would also add safety if the offsets the table is mistakenly computed
> (from the current code, I can't convince myself the offset will always
> be right).

As far as I understand, we would still need to use the same offsets even
if we used vgic_access_guest_memory. Also, the only significant
difference between my implementation and vgic_access_guest_memory is
that gic_access_guest_memory checks whether we write over page
boundaries, which is quite hard to achieve as the offsets are limited in
number so that they don't cross page boundaries.

Yet, if you insist, I will try to incorporate vgic_access_guest_memory
into my implementation.

Thanks,
~Sergej



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2017-06-23 19:02 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-20 20:33 [PATCH v4 0/9] arm/mem_access: Walk guest page tables in SW if mem_access is active Sergej Proskurin
2017-06-20 20:33 ` [PATCH v4 1/9] arm/mem_access: Add (TCR_|TTBCR_)* defines Sergej Proskurin
2017-06-22 10:42   ` Julien Grall
2017-06-20 20:33 ` [PATCH v4 2/9] arm/mem_access: Add defines supporting PTs with varying page sizes Sergej Proskurin
2017-06-22 10:52   ` Julien Grall
2017-06-20 20:33 ` [PATCH v4 3/9] arm/mem_access: Add short-descriptor pte typedefs Sergej Proskurin
2017-07-04 16:22   ` Julien Grall
2017-07-04 16:24     ` Julien Grall
2017-06-20 20:33 ` [PATCH v4 4/9] arm/mem_access: Introduce GV2M_EXEC permission Sergej Proskurin
2017-06-20 20:33 ` [PATCH v4 5/9] arm/mem_access: Extend BIT-operations to unsigned long long Sergej Proskurin
2017-06-22 11:13   ` Julien Grall
2017-06-20 20:33 ` [PATCH v4 6/9] arm/mem_access: Add software guest-page-table walk Sergej Proskurin
2017-06-22 11:16   ` Julien Grall
2017-06-22 11:36     ` Sergej Proskurin
2017-06-20 20:33 ` [PATCH v4 7/9] arm/mem_access: Add long-descriptor based gpt Sergej Proskurin
2017-06-22 12:12   ` Julien Grall
2017-06-23 14:23     ` Sergej Proskurin
2017-06-23 14:35       ` Julien Grall
2017-06-22 13:54   ` Julien Grall
2017-06-20 20:33 ` [PATCH v4 8/9] arm/mem_access: Add short-descriptor " Sergej Proskurin
2017-06-22 13:53   ` Julien Grall
2017-06-23 19:09     ` Sergej Proskurin [this message]
2017-06-23 20:46       ` Julien Grall
2017-06-26  7:57         ` Sergej Proskurin
2017-06-20 20:33 ` [PATCH v4 9/9] arm/mem_access: Walk the guest's pt in software Sergej Proskurin
2017-06-20 20:44   ` Tamas K Lengyel
2017-06-20 20:59     ` Sergej Proskurin

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=d477979e-146a-62b7-86d5-a85f4779597d@sec.in.tum.de \
    --to=proskurin@sec.in.tum.de \
    --cc=julien.grall@arm.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /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).