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: [RFC PATCH v2 5/8] arm/mem_access: Add software guest-page-table walk
Date: Thu, 8 Jun 2017 14:43:47 +0200 [thread overview]
Message-ID: <0da289b1-e2ef-672e-3a3d-0ac86fc1d663@sec.in.tum.de> (raw)
In-Reply-To: <3a019bbf-6ebe-85b0-4d97-90ccb6295035@arm.com>
Hi Julien,
[...]
> I know I suggested to move in p2m.c. Looking at the diff stat, this
> will increase quite a lot p2m.c which is already big.
>
> How about introducing a file guest_walk.c which contain the new
> functions?
>
No problem at all. I will gladly move the functionality into a separate
file.
>
>> + vaddr_t gva, paddr_t *ipa,
>> + unsigned int *perm_ro)
>
> I am a bit confused with perm_ro. Will you only return 0/1? If so it
> should be a bool.
>
> But we likely want to know more permission such as the execution bit...
>
Yes, I agree that we should return more permissions back to the caller.
I suggest that we agree on required permissions at this point, as do not
only have the execution bit (!XN) but also we distinguish between the
Privileged XN (PXN) bit in the long-descriptor format, as well as the
access permissions bits (AP[2:x]), which inform which EL/PL is allowed
to access (RWX) the particular memory region.
Or do you think returning an additional execute bit (!XN) would suffice
for now, as we don't really care about execution permissions at
different EL's/PL's at this point?
>
>
> The name gpt is not very used in Xen and would prefer a clearer name
> such as the x86 one "guest_walk_tables".
Sounds good to me. I have changed the names to guest_walk_(tables|sd|ld).
>
>> + paddr_t *ipa, unsigned int *perm_ro)
>> +{
>> + uint32_t sctlr = READ_SYSREG(SCTLR_EL1);
>> + register_t tcr = READ_SYSREG(TCR_EL1);
>> +#ifdef CONFIG_ARM_64
>> + struct domain *d = p2m->domain;
>> +#endif
>
> The only place use *d is in the is_32bit_domain, so no need to add
> some #ifdef and define the variable.
>
[...]
>> +
>> +#ifdef CONFIG_ARM_64
>> + if ( is_32bit_domain(d) )
>> +#endif
>
> is_32bit_domain exists for 32-bit Xen. So not need to have this #ifdef.
>
True. The reason for this #ifdef is that since is_32bit_domain(d)
resolves to a (1) on ARMv7, the compiler complained about the fact that
the variable struct domain *d was not used. To resolve this, I can
simply use p2m->domain at this point and remove the local variable
completely. Alternatively, I could use struct domain *d as a function
parameter instead of struct p2m_domain *p2m. I believe it would be
cleaner to provide the domain instead of the p2m as parameter, as we
don't really need the p2m. What would you prefer?
Cheers,
~Sergej
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-06-08 12:43 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-01 15:18 [RFC PATCH v2 0/8] arm/mem_access: Walk guest page tables in SW if mem_access is active Sergej Proskurin
2017-06-01 15:18 ` [RFC PATCH v2 1/8] arm/mem_access: Add (TCR_|TTBCR_)* defines Sergej Proskurin
2017-06-02 7:31 ` Julien Grall
2017-06-07 14:56 ` Sergej Proskurin
2017-06-07 15:07 ` Julien Grall
2017-06-07 15:11 ` Julien Grall
2017-06-01 15:18 ` [RFC PATCH v2 2/8] arm/mem_access: Add defines holding the width of 32/64bit regs Sergej Proskurin
2017-06-01 15:18 ` [RFC PATCH v2 3/8] arm/mem_access: Add defines supporting PTs with varying page sizes Sergej Proskurin
2017-06-02 8:27 ` Julien Grall
2017-06-01 15:18 ` [RFC PATCH v2 4/8] arm/mem_access: Add short-descriptor pte typedefs Sergej Proskurin
2017-06-02 8:50 ` Julien Grall
2017-06-01 15:18 ` [RFC PATCH v2 5/8] arm/mem_access: Add software guest-page-table walk Sergej Proskurin
2017-06-02 9:02 ` Julien Grall
2017-06-08 12:43 ` Sergej Proskurin [this message]
2017-06-09 8:19 ` Julien Grall
2017-06-01 15:18 ` [RFC PATCH v2 6/8] arm/mem_access: Add long-descriptor based gpt Sergej Proskurin
2017-06-02 12:55 ` Julien Grall
2017-06-09 11:50 ` Sergej Proskurin
2017-06-09 12:39 ` Julien Grall
2017-06-12 10:12 ` Sergej Proskurin
2017-06-12 10:44 ` Julien Grall
2017-06-12 12:31 ` Sergej Proskurin
2017-06-01 15:18 ` [RFC PATCH v2 7/8] arm/mem_access: Add short-descriptor " Sergej Proskurin
2017-06-02 15:11 ` Julien Grall
2017-06-01 15:18 ` [RFC PATCH v2 8/8] arm/mem_access: Walk the guest's pt in software Sergej Proskurin
2017-06-01 15:18 ` [PATCH 1/8] arm/mem_access: Add (TCR_|TTBCR_)* defines Sergej Proskurin
2017-06-02 15:13 ` Julien Grall
2017-06-03 8:56 ` Sergej Proskurin
2017-06-01 15:19 ` [PATCH 2/8] arm/mem_access: Add defines holding the width of 32/64bit regs Sergej Proskurin
2017-06-01 15:19 ` [PATCH 3/8] arm/mem_access: Add defines supporting PTs with varying page sizes Sergej Proskurin
2017-06-01 15:19 ` [PATCH 4/8] arm/mem_access: Add short-descriptor pte typedefs Sergej Proskurin
2017-06-01 15:19 ` [PATCH 5/8] arm/mem_access: Add software guest-page-table walk Sergej Proskurin
2017-06-01 15:19 ` [PATCH 6/8] arm/mem_access: Add long-descriptor based gpt Sergej Proskurin
2017-06-01 15:19 ` [PATCH 7/8] arm/mem_access: Add short-descriptor " Sergej Proskurin
2017-06-01 15:19 ` [PATCH 8/8] arm/mem_access: Walk the guest's pt in software 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=0da289b1-e2ef-672e-3a3d-0ac86fc1d663@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).