All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrii Anisov <andrii.anisov@gmail.com>
To: Julien Grall <julien.grall@arm.com>, xen-devel@lists.xen.org
Cc: "Juergen Gross" <jgross@suse.com>,
	"Andrii Anisov" <andrii_anisov@epam.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH 0/2 for-4.12] Introduce runstate area registration with phys address
Date: Thu, 7 Mar 2019 16:34:03 +0200	[thread overview]
Message-ID: <e98e3651-c780-0bb8-d2ad-db1675b00c28@gmail.com> (raw)
In-Reply-To: <59a2f220-5c90-381c-2c52-bb2cdb813e8e@arm.com>



On 07.03.19 16:02, Julien Grall wrote:
>> So I assume you say about you preferences to not have runstate area mapped because of consuming vmap space for arm64. Also, along that thread you mentioned you that guest might change gva mapping, what is irrelevant to registration with physical address.
>>
>> My reasons to have that runstate mapped are following:
>>   - Introducing the new interface we are not burden with legacy, so in charge to impose requirements. In this case - to have runstate area not crossing a page boundary
>>   - Global mapping used here does not consume vmap space on arm64. It seems to me x86 guys are ok with mapping as well, at least Roger suggested it from the beginning. So it should be ok for them as well.
> You left arm32 out of your equations here...
Yes, I left arm32 aside.

>>   - In case domain is mapping runstate with physical address, it can not change the mapping.
> 
> This is not entirely correct. The domain can not change the mapping under our feet, but it can still change via the hypercall. There are nothing preventing that with current hypercall and the one your propose.
Could you please describe the scenario with more details and the interface used for it?
Also vcpu_info needs protections from it. Do you agree?

> Well the number you showed in the other thread didn't show any improvement at all... So please explain why we should call map_domain_page_global() here and using more vmap on arm32
I'm not expecting vmap might be a practical problem for arm32 based system.
With the current implementation numbers are equal to those I have for runstate mapping on access.
But I'm not sure my test setup able to distinguish the difference.

>>   - IMHO, this implementation is simpler and cleaner than what I have for runstate mapping on access.
> 
> Did you implement it using access_guest_memory_by_ipa?
Not exactly, access_guest_memory_by_ipa() has no implementation for x86. But it is made around that code.
  
> But I don't think the implementation you suggest will be that simpler once you deal with the problem above.I missed that problem. Will look at it.

-- 
Sincerely,
Andrii Anisov.

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

  reply	other threads:[~2019-03-07 14:34 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-05 13:14 [PATCH 0/2 for-4.12] Introduce runstate area registration with phys address Andrii Anisov
2019-03-05 13:14 ` [PATCH 1/2 for-4.12] xen: introduce VCPUOP_register_runstate_phys_memory_area hypercall Andrii Anisov
2019-03-14  8:45   ` Jan Beulich
2019-03-05 13:14 ` [PATCH 2/2 for-4.12] xen: implement VCPUOP_register_runstate_phys_memory_area Andrii Anisov
2019-03-14  9:05   ` Jan Beulich
2019-03-05 13:20 ` [PATCH 0/2 for-4.12] Introduce runstate area registration with phys address Juergen Gross
2019-03-05 13:32   ` Andrii Anisov
2019-03-05 13:39     ` Julien Grall
2019-03-05 14:11       ` Andrii Anisov
2019-03-05 14:30         ` Julien Grall
2019-03-07 13:07           ` Andrii Anisov
2019-03-05 13:44     ` Juergen Gross
2019-03-05 13:50       ` Andrii Anisov
2019-03-05 13:56 ` Julien Grall
2019-03-07 13:01   ` Andrii Anisov
2019-03-07 14:02     ` Julien Grall
2019-03-07 14:34       ` Andrii Anisov [this message]
2019-03-07 15:17         ` Julien Grall
2019-03-07 15:20           ` Julien Grall
2019-03-07 16:16           ` Roger Pau Monné
2019-03-07 16:36             ` Julien Grall
2019-03-07 17:15               ` Roger Pau Monné
2019-03-07 18:00                 ` Julien Grall
2019-03-08  6:28                   ` Juergen Gross
2019-03-08 10:15                     ` Julien Grall
2019-03-08 10:18                       ` Juergen Gross
2019-03-08 10:31                         ` Julien Grall
2019-03-18 11:31           ` Andrii Anisov
2019-03-18 12:25             ` Julien Grall
2019-03-18 13:38               ` Andrii Anisov
2019-03-21 19:05                 ` Julien Grall

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=e98e3651-c780-0bb8-d2ad-db1675b00c28@gmail.com \
    --to=andrii.anisov@gmail.com \
    --cc=andrii_anisov@epam.com \
    --cc=jgross@suse.com \
    --cc=julien.grall@arm.com \
    --cc=roger.pau@citrix.com \
    --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.