From: Julien Grall <julien.grall@arm.com>
To: "Andrii Anisov" <andrii.anisov@gmail.com>,
"Roger Pau Monné" <roger.pau@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
"LOPEZ, FUENTES NACARINO Jairo Eduardo" <jairo@ruri.waseda.jp>,
xen-devel@lists.xen.org
Subject: Re: RT Xen on ARM - R-Car series
Date: Mon, 4 Feb 2019 11:21:02 +0000 [thread overview]
Message-ID: <015ee6f9-3ce0-d579-78e0-7f8502e0f447@arm.com> (raw)
In-Reply-To: <80fd1e04-6984-5b59-42cc-3b486fd218fa@gmail.com>
On 2/4/19 10:28 AM, Andrii Anisov wrote:
> Hello,
Hi Andrii,
> On 01.02.19 19:40, Julien Grall wrote:
>> On 01/02/2019 16:53, Roger Pau Monné wrote:
>>> On Thu, Jan 31, 2019 at 11:14:37PM +0000, Julien Grall wrote:
>>>> On 1/31/19 9:56 PM, Stefano Stabellini wrote:
>>>>> On Thu, 31 Jan 2019, Julien Grall wrote:
>>>>>> On 31/01/2019 12:00, Andrii Anisov wrote:
>>>>>>> On 31.01.19 13:37, Julien Grall wrote:
>>> So, I've got a hacky patch to 'fix' this on x86, by taking a reference
>>> to the mfn behind the virtual address provided when setting up the
>>> hypercall and mapping it in Xen.
>>
>> That was the idea I had in mind :).
> Looks interesting.
>
>> Hopefully, no guest is modifying the mapping (i.e the virtual address
>> point to a different physical address) afterwards.
> I guess, that mapping should not be moved around. Otherwise it would be
> broken even with the current implementation.
What I meant is the virtual address stays the same but the guest
physical address may change. I don't see how this could be broken today,
can you explain it?
> Moreover, having that buffer mapped to XEN will reduce context switch
> time as a side effect.
I am still unsure whether we really want to keep that always mapped.
Each guest can support up to 128 vCPUs. So we would have 128 runstates
mapped. Each runstate would take up to 2 pages. This means that each
guest would require up to 1MB of vmap.
The VMAP in Xen is quite limited (1GB at most) and shared with device
mapping (e.g ITS...).
On the other side, not mapping the pages contiguously is going to be a
pain. So maybe the downside is worth it. It would be interesting to have
the pros/cons of each solution written down in the series.
>
>>> This however doesn't work on ARM due
>>> to the lack of paging_gva_to_gfn. I guess there's something similar to
>>> translate a guest virtual address into a gfn or a mfn?
>>
>> get_page_from_gva should to the job for you.
>>> +int map_runstate_area(struct vcpu *v,
>>> + struct vcpu_register_runstate_memory_area *area)
>>> +{
>>> + unsigned long offset;
>>> + unsigned int i;
>>> + struct domain *d = v->domain;
>>> + size_t size =
>>> +#ifdef CONFIG_COMPAT
>>> + has_32bit_shinfo((v)->domain) ?
>>> sizeof(*v->compat_runstate_guest) :
>>> +#endif
>>> + sizeof(*v->runstate_guest);
>>> +
>>> + if ( v->runstate_guest )
>>> + {
>>> + ASSERT_UNREACHABLE();
>>> + return -EBUSY;
>>> + }
>>> +
>>> + offset = area->addr.p & ~PAGE_MASK;
>>> +
>>> + for ( i = 0; i < ARRAY_SIZE(v->runstate_mfn); i++ )
>>> + {
>>> + p2m_type_t t;
>>> + uint32_t pfec = PFEC_page_present;
>>> + gfn_t gfn = _gfn(paging_gva_to_gfn(v, area->addr.p, &pfec));
>>> + struct page_info *pg;
>>> +
>>> + if ( gfn_eq(gfn, INVALID_GFN) )
>>> + return -EFAULT;
>>> +
>>> + v->runstate_mfn[i] = get_gfn(d, gfn_x(gfn), &t);
>>
>> get_gfn would need to be implemented on Arm.
> I'm going to step into this, tomorrow I guess. I have to finish smth today.
I thought more about it during the week-end. I would actually not
implement get_gfn but implement a function similar to get_page_from_gva
on x86. The reason behind this is the function on Arm is quite complex
as it caters many different use case.
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-02-04 11:21 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CACrvCsaeHuwzZzUQTzNYF7fqmgQWNJUVOQZv9D0MnYrXjqzZtQ@mail.gmail.com>
2018-12-22 12:21 ` RT Xen on ARM - R-Car series Andrii Anisov
2018-12-25 16:07 ` LOPEZ, FUENTES NACARINO Jairo Eduardo
2018-12-27 11:07 ` Andrii Anisov
2018-12-28 15:22 ` LOPEZ, FUENTES NACARINO Jairo Eduardo
2018-12-28 8:28 ` Andrii Anisov
2018-12-28 8:32 ` Andrii Anisov
2018-12-28 8:39 ` Andrii Anisov
2019-01-04 9:09 ` LOPEZ, FUENTES NACARINO Jairo Eduardo
2019-01-08 17:04 ` LOPEZ, FUENTES NACARINO Jairo Eduardo
2019-01-11 20:12 ` LOPEZ, FUENTES NACARINO Jairo Eduardo
2019-01-14 8:42 ` Andrii Anisov
2019-01-16 7:53 ` Andrii Anisov
2019-01-21 18:04 ` LOPEZ, FUENTES NACARINO Jairo Eduardo
[not found] ` <CACrvCsZB-tps6=Vr=1Phf5oo5eUReabMLJzkbO3d2hmNLDOxww@mail.gmail.com>
[not found] ` <7e217489-2c1a-c35f-d51f-0969654aa8cc@gmail.com>
[not found] ` <CACrvCsaYJ-zGkZwfdV7BXDABW8u_EDQetU3pq+2otRGXWTXagw@mail.gmail.com>
[not found] ` <4d078801-b804-06e7-ad5c-8032b1dbaa84@gmail.com>
2019-01-28 17:20 ` LOPEZ, FUENTES NACARINO Jairo Eduardo
2019-01-28 8:25 ` Andrii Anisov
2019-01-29 15:30 ` LOPEZ, FUENTES NACARINO Jairo Eduardo
2019-01-29 13:29 ` Andrii Anisov
2019-01-30 20:23 ` LOPEZ, FUENTES NACARINO Jairo Eduardo
2019-01-30 12:12 ` Julien Grall
2019-01-31 11:22 ` Andrii Anisov
2019-01-31 11:37 ` Julien Grall
2019-01-31 12:00 ` Andrii Anisov
2019-01-31 12:20 ` Julien Grall
2019-01-31 21:56 ` Stefano Stabellini
2019-01-31 23:14 ` Julien Grall
2019-02-01 10:02 ` Andrii Anisov
2019-02-01 10:12 ` Julien Grall
2019-02-01 10:35 ` Andrii Anisov
2019-02-01 11:06 ` Julien Grall
2019-02-01 16:53 ` Roger Pau Monné
2019-02-01 17:40 ` Julien Grall
2019-02-04 10:28 ` Andrii Anisov
2019-02-04 11:21 ` Julien Grall [this message]
2019-02-04 14:46 ` Andrii Anisov
2019-02-04 15:05 ` Julien Grall
2019-02-04 12:53 ` Roger Pau Monné
2019-02-04 21:58 ` Julien Grall
2019-02-05 8:40 ` Andrii Anisov
2019-02-05 9:45 ` Roger Pau Monné
2019-02-05 9:54 ` Andrii Anisov
2019-02-05 10:10 ` Roger Pau Monné
2019-02-06 20:20 ` Andrii Anisov
2019-02-06 21:03 ` Stefano Stabellini
2019-02-07 9:42 ` Andrii Anisov
2019-02-07 10:35 ` Roger Pau Monné
2019-02-07 10:59 ` Julien Grall
2019-02-12 18:21 ` Andrii Anisov
2019-02-12 19:21 ` Julien Grall
2019-02-14 14:18 ` Andrii Anisov
2019-02-14 17:29 ` Julien Grall
2019-02-15 11:30 ` Andrii Anisov
2019-02-15 17:13 ` Julien Grall
2019-02-15 17:41 ` Andrii Anisov
2019-02-16 8:42 ` Julien Grall
2019-02-12 18:21 ` Andrii Anisov
2019-02-14 16:29 ` Roger Pau Monné
2019-02-15 15:21 ` Andrii Anisov
2019-02-15 16:31 ` Julien Grall
2019-02-15 17:30 ` Andrii Anisov
2019-02-15 18:36 ` Julien Grall
2019-02-14 17:08 ` Julien Grall
2019-02-05 9:26 ` Roger Pau Monné
2019-02-01 10:07 ` Andrii Anisov
2019-02-01 10:16 ` Julien Grall
2019-02-01 10:35 ` Andrii Anisov
2019-02-01 10:51 ` Julien Grall
2019-02-01 18:00 ` Stefano Stabellini
2019-02-04 10:32 ` Andrii Anisov
2019-02-04 11:36 ` Julien Grall
2019-02-04 15:19 ` Andrii Anisov
2019-02-04 22:06 ` Julien Grall
2019-02-05 9:01 ` Andrii Anisov
2019-02-05 19:18 ` Stefano Stabellini
2019-02-07 10:53 ` Andrii Anisov
[not found] ` <CACrvCsbkFG=3To83qi7xxmtmgC_9PKvuLz73edhiaV7TsJAZqQ@mail.gmail.com>
2019-01-31 12:24 ` Julien Grall
2019-01-16 20:46 ` Andrii Anisov
2019-01-16 7:40 ` Andrii Anisov
2019-01-17 2:08 ` LOPEZ, FUENTES NACARINO Jairo Eduardo
2018-12-28 17:35 ` LOPEZ, FUENTES NACARINO Jairo Eduardo
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=015ee6f9-3ce0-d579-78e0-7f8502e0f447@arm.com \
--to=julien.grall@arm.com \
--cc=andrii.anisov@gmail.com \
--cc=jairo@ruri.waseda.jp \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xen.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.