From: Julien Grall <julien.grall@arm.com>
To: Andrii Anisov <andrii.anisov@gmail.com>, xen-devel@lists.xen.org
Cc: "Stefano Stabellini" <sstabellini@kernel.org>,
"Andrii Anisov" <andrii_anisov@epam.com>,
"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
"George Dunlap" <George.Dunlap@eu.citrix.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Ian Jackson" <ian.jackson@eu.citrix.com>,
"Tim Deegan" <tim@xen.org>, "Jan Beulich" <JBeulich@suse.com>,
xen-devel@lists.xenproject.org, "Wei Liu" <wei.liu2@citrix.com>,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 2/2] xen: implement VCPUOP_register_runstate_phys_memory_area
Date: Tue, 14 May 2019 10:58:24 +0100 [thread overview]
Message-ID: <24f3e2b1-4889-1780-0e48-0c909f555997@arm.com> (raw)
Message-ID: <20190514095824.qQsXlQHCK_z4e5QFtp-4CQ7Ya4iwL4WGkAM0xTrxyzU@z> (raw)
In-Reply-To: <959c8975-ec44-a788-25b3-84ee17520abc@gmail.com>
On 13/05/2019 13:30, Andrii Anisov wrote:
>
>
> On 08.05.19 18:40, Julien Grall wrote:
>>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
>>> index 6dc633e..8e24e63 100644
>>
>>> {
>>> - void __user *guest_handle = NULL;
>>> + if ( !guest_handle_is_null(runstate_guest(v)) )
>>> + {
>>> + void __user *guest_handle = NULL;
>>> + if ( VM_ASSIST(v->domain, runstate_update_flag) )
>>> + {
>>> + guest_handle = &v->runstate_guest.p->state_entry_time + 1;
>>> + guest_handle--;
>>> + v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE;
>>> + __raw_copy_to_guest(guest_handle,
>>> + (void *)(&v->runstate.state_entry_time + 1)
>>> - 1,
>>> + 1);
>>> + smp_wmb();
>>> + }
>>> - if ( guest_handle_is_null(runstate_guest(v)) )
>>> - return;
>>> + __copy_to_guest(runstate_guest(v), &v->runstate, 1);
>>> - if ( VM_ASSIST(v->domain, runstate_update_flag) )
>>> - {
>>> - guest_handle = &v->runstate_guest.p->state_entry_time + 1;
>>> - guest_handle--;
>>> - v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE;
>>> - __raw_copy_to_guest(guest_handle,
>>> - (void *)(&v->runstate.state_entry_time + 1) - 1,
>>> 1);
>>> - smp_wmb();
>>> + if ( guest_handle )
>>> + {
>>> + v->runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE;
>>> + smp_wmb();
>>> + __raw_copy_to_guest(guest_handle,
>>> + (void *)(&v->runstate.state_entry_time + 1)
>>> - 1,
>>> + 1);
>>> + }
>>> }
>>> - __copy_to_guest(runstate_guest(v), &v->runstate, 1);
>>> -
>>> - if ( guest_handle )
>>> + spin_lock(&v->mapped_runstate_lock);
>>> + if ( v->mapped_runstate )
>>
>> The code looks a bit odd to me, you seem to allow a guest to provide 2
>> runstate areas: one using guest virtual address the other using guest physical
>> address.
>>
>> It would be best if we prevent a guest to mix match them.
>
> Firstly I turned to implementing in that way, but the locking and decissions
> code become really ugly and complex while trying to cover 'guest's misbehavior'
> scenarios.
I think it is possible to have a simple version taking the decision on which
method to use. You can either use the spin_lock to protect everything or use
something like:
update_runstate_area():
if ( xchg(&v->runstate_in_use, 1) )
return;
switch ( v->runstate_type )
{
GVADDR:
update_runstate_by_gvaddr();
GPADDR:
update_runstate_by_gpaddr();
}
xchg(&v->runstate_in_use, 0);
registering an area
while ( xchg(&v->runstate_in_use, 1) );
/* Clean-up and registering the area */
>
>> IOW, if the guest provide a physical address first, then *all* the call should
>> be physical address. Alternatively this could be a per vCPU decision.
>
> I guess we should agree what to implement first.
I think there are an agreement that the two methods should not be used together.
[..]
>>> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
>>> index 312fec8..3fb6ea2 100644
>>> --- a/xen/include/asm-arm/domain.h
>>> +++ b/xen/include/asm-arm/domain.h
>>> @@ -217,6 +217,8 @@ void vcpu_show_execution_state(struct vcpu *);
>>> void vcpu_show_registers(const struct vcpu *);
>>> void vcpu_switch_to_aarch64_mode(struct vcpu *);
>>> +void update_runstate_area(struct vcpu *);
>>> +
>>> /*
>>> * Due to the restriction of GICv3, the number of vCPUs in AFF0 is
>>> * limited to 16, thus only the first 4 bits of AFF0 are legal. We will
>>> diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
>>> index d1bfc82..ecddcfe 100644
>>> --- a/xen/include/xen/domain.h
>>> +++ b/xen/include/xen/domain.h
>>> @@ -118,4 +118,6 @@ struct vnuma_info {
>>> void vnuma_destroy(struct vnuma_info *vnuma);
>>> +struct vcpu_register_runstate_memory_area;
>>> +
>>> #endif /* __XEN_DOMAIN_H__ */
>>> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
>>> index 748bb0f..2afe31c 100644
>>> --- a/xen/include/xen/sched.h
>>> +++ b/xen/include/xen/sched.h
>>> @@ -163,15 +163,23 @@ struct vcpu
>>> void *sched_priv; /* scheduler-specific data */
>>> struct vcpu_runstate_info runstate;
>>> +
>>> + spinlock_t mapped_runstate_lock;
>>> +
>>> #ifndef CONFIG_COMPAT
>>> # define runstate_guest(v) ((v)->runstate_guest)
>>> XEN_GUEST_HANDLE(vcpu_runstate_info_t) runstate_guest; /* guest address */
>>> + vcpu_runstate_info_t *mapped_runstate;
>>> #else
>>> # define runstate_guest(v) ((v)->runstate_guest.native)
>>> union {
>>> XEN_GUEST_HANDLE(vcpu_runstate_info_t) native;
>>> XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t) compat;
>>> } runstate_guest; /* guest address */
>>> + union {
>>> + vcpu_runstate_info_t* native;
>>> + vcpu_runstate_info_compat_t* compat;
>>> + } mapped_runstate; /* guest address */
>> > The combination of mapped_runstate and runstate_guest is a bit confusing. I
>> think you want to rework the interface to show that only one is possible at
>> the time and make clear which one is used by who. Maybe:
>
> As I said before, IMO coupling those interfaces makes the code complicated and
> ugly.
Well, I can't see how it can be ugly (see my example above).
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-05-14 9:58 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-23 8:10 [PATCH v2 0/2] Introduce runstate area registration with phys address Andrii Anisov
2019-04-23 8:10 ` [PATCH v2 1/2] xen: introduce VCPUOP_register_runstate_phys_memory_area hypercall Andrii Anisov
2019-04-23 8:10 ` [Xen-devel] " Andrii Anisov
2019-05-08 10:10 ` George Dunlap
2019-05-08 10:10 ` [Xen-devel] " George Dunlap
2019-04-23 8:10 ` [PATCH v2 2/2] xen: implement VCPUOP_register_runstate_phys_memory_area Andrii Anisov
2019-04-23 8:10 ` [Xen-devel] " Andrii Anisov
2019-05-08 15:40 ` Julien Grall
2019-05-08 15:40 ` [Xen-devel] " Julien Grall
2019-05-09 9:27 ` Jan Beulich
2019-05-09 9:27 ` [Xen-devel] " Jan Beulich
2019-05-14 9:35 ` Julien Grall
2019-05-14 9:35 ` [Xen-devel] " Julien Grall
2019-05-14 9:48 ` Jan Beulich
2019-05-14 9:48 ` [Xen-devel] " Jan Beulich
2019-05-14 11:23 ` Julien Grall
2019-05-14 11:23 ` [Xen-devel] " Julien Grall
2019-05-14 11:29 ` Jan Beulich
2019-05-14 11:29 ` [Xen-devel] " Jan Beulich
2019-05-13 12:30 ` Andrii Anisov
2019-05-13 12:30 ` [Xen-devel] " Andrii Anisov
2019-05-14 9:58 ` Julien Grall [this message]
2019-05-14 9:58 ` Julien Grall
2019-05-14 10:08 ` Andrii Anisov
2019-05-14 10:08 ` [Xen-devel] " Andrii Anisov
2019-05-14 11:24 ` Julien Grall
2019-05-14 11:24 ` [Xen-devel] " Julien Grall
2019-05-14 11:45 ` Andrii Anisov
2019-05-14 11:45 ` [Xen-devel] " Andrii Anisov
2019-05-14 12:02 ` Jan Beulich
2019-05-14 12:02 ` [Xen-devel] " Jan Beulich
2019-05-14 13:05 ` Andrii Anisov
2019-05-14 13:05 ` [Xen-devel] " Andrii Anisov
2019-05-14 13:49 ` Julien Grall
2019-05-14 13:49 ` [Xen-devel] " Julien Grall
2019-05-15 9:04 ` Andrii Anisov
2019-05-15 9:04 ` [Xen-devel] " Andrii Anisov
2019-05-15 10:31 ` Julien Grall
2019-05-15 10:31 ` [Xen-devel] " Julien Grall
2019-05-14 13:49 ` Jan Beulich
2019-05-14 13:49 ` [Xen-devel] " Jan Beulich
2019-05-15 8:44 ` Andrii Anisov
2019-05-15 8:44 ` [Xen-devel] " Andrii Anisov
2019-05-15 11:59 ` Jan Beulich
2019-05-15 11:59 ` [Xen-devel] " Jan Beulich
2019-05-16 12:09 ` Jan Beulich
2019-05-16 12:09 ` [Xen-devel] " Jan Beulich
2019-05-16 13:30 ` Andrii Anisov
2019-05-16 13:30 ` [Xen-devel] " Andrii Anisov
2019-05-16 13:30 ` Andrii Anisov
2019-05-16 13:30 ` [Xen-devel] " Andrii Anisov
2019-05-16 13:48 ` Julien Grall
2019-05-16 13:48 ` [Xen-devel] " Julien Grall
2019-05-16 14:25 ` Andrii Anisov
2019-05-16 14:25 ` [Xen-devel] " Andrii Anisov
2019-05-16 14:28 ` Julien Grall
2019-05-16 14:28 ` [Xen-devel] " Julien Grall
2019-05-16 14:29 ` Andrii Anisov
2019-05-16 14:29 ` [Xen-devel] " Andrii Anisov
[not found] ` <fa126315-31af-854e-817a-8640b431c82b@arm.com>
[not found] ` <CAC1WxdiMzAq5hRC-mhRQuFDs7z_Hj5w7VAy52ec87SJQOGmp3w@mail.gmail.com>
[not found] ` <a28f95a1-d9da-2caf-f4b4-013100176b02@arm.com>
[not found] ` <090ce8cc-f329-fe54-4894-b7f12e3cd5a6@gmail.com>
2019-05-08 13:39 ` [PATCH v2 0/2] Introduce runstate area registration with phys address Julien Grall
2019-05-08 13:39 ` [Xen-devel] " Julien Grall
2019-05-08 13:54 ` Andrii Anisov
2019-05-08 13:54 ` [Xen-devel] " Andrii Anisov
2019-05-08 14:31 ` Julien Grall
2019-05-08 14:31 ` [Xen-devel] " Julien Grall
2019-05-08 16:01 ` Andrii Anisov
2019-05-08 16:01 ` [Xen-devel] " Andrii Anisov
2019-05-13 10:50 ` Julien Grall
2019-05-13 10:50 ` [Xen-devel] " Julien Grall
2019-05-13 14:34 ` Andrii Anisov
2019-05-13 14:34 ` [Xen-devel] " Andrii Anisov
2019-05-08 13:59 ` Julien Grall
2019-05-13 10:15 ` Andrii Anisov
2019-05-13 11:16 ` Julien Grall
2019-05-13 14:14 ` Andrii Anisov
2019-05-13 14:34 ` Julien Grall
2019-05-13 15:29 ` Andrii Anisov
2019-05-13 15:31 ` Julien Grall
2019-05-13 15:38 ` Andrii Anisov
2019-05-13 15:40 ` Julien Grall
2019-05-13 15:42 ` Andrii Anisov
2019-05-13 15:45 ` Julien Grall
2019-05-13 16:05 ` Andrii Anisov
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=24f3e2b1-4889-1780-0e48-0c909f555997@arm.com \
--to=julien.grall@arm.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=andrii.anisov@gmail.com \
--cc=andrii_anisov@epam.com \
--cc=ian.jackson@eu.citrix.com \
--cc=konrad.wilk@oracle.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=tim@xen.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.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).