From: Julien Grall <julien.grall@arm.com> To: Andrii Anisov <andrii.anisov@gmail.com>, Jan Beulich <JBeulich@suse.com> Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wei.liu2@citrix.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>, xen-devel <xen-devel@lists.xenproject.org>, "andrii_anisov@epam.com" <andrii_anisov@epam.com>, Roger Pau Monne <roger.pau@citrix.com> Subject: Re: [PATCH v2 2/2] xen: implement VCPUOP_register_runstate_phys_memory_area Date: Wed, 15 May 2019 11:31:56 +0100 [thread overview] Message-ID: <a59d8d2e-0858-dc9c-466e-860657727698@arm.com> (raw) In-Reply-To: <c58b5000-623d-766e-eba8-a4df1fbe1a44@gmail.com> Hi Andrii, On 15/05/2019 10:04, Andrii Anisov wrote: > > > On 14.05.19 16:49, Julien Grall wrote: >> You have to keep in mind that existing OS have to run on newer Xen without any >> modification. > > As I just written to Jan, it is one more reason to keep those interfaces living > in parallel and do not mix their implementation. There are actually no good reason for a guest to register via the two interfaces at the same time. The more we want to encourage the OS developer to switch to the new interface. I also provided in my previous e-mails way to make the two working together without much trouble. > >> The existing hypercall allows you to: >> 1) De-register an interface using the value 0. > > My current implementation can easily be updated with the same behavior. > >> 2) Replacing a current existing interface > >> You probably can't use 2) for a bootloader -> kernel handover because we are >> dealing with guest virtual address. There is an high chance the virtual >> address space layout is going to be different or even turning off MMU for a >> bit (done on Arm). So you have to use 1) otherwise you might write in a random >> place in memory. > > This definitely not the way to handle transitions between systems in a guest > domain. > >> I am not entirely sure whether there are actual value for 2). The only reason >> I can think of is if you want to move around the runstate in your virtual >> address space. But that's sounds a bit weird at least on Arm. >> For the new hypercall, I think we at least want 1) (with a magic value TBD). > > The magic value 0x0 can easily be introduced. 0x0 is not an option. It could be a valid physical address. We need a value that cannot be used by anyone. > >> 2) might be helpful in the case the bootloader didn't do the right thing or >> we are using Kexec to boot a new kernel. This would also be safer as physical >> address could be excluded more easily. > > But the new system have to get some knowledge about the previous phys addr is > reserved (used by hypervisor), and do not use it prior to registering new > runstate area. > Providing such a knowledge is something (e.g.) the bootloader should take care > of. But, IMO, it is better to require from (e.g.) the bootloader to unregister > its runstate area prior to switching to the new system. Well, if a bootloader keep some part in memory (such as for handling runtime services), it will usually mark those pages are reserved. So it can't be used by the kernel. But here, the point is it would not be difficult to handle 2). So why would you try to forbid it? Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
WARNING: multiple messages have this Message-ID (diff)
From: Julien Grall <julien.grall@arm.com> To: Andrii Anisov <andrii.anisov@gmail.com>, Jan Beulich <JBeulich@suse.com> Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wei.liu2@citrix.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>, xen-devel <xen-devel@lists.xenproject.org>, "andrii_anisov@epam.com" <andrii_anisov@epam.com>, Roger Pau Monne <roger.pau@citrix.com> Subject: Re: [Xen-devel] [PATCH v2 2/2] xen: implement VCPUOP_register_runstate_phys_memory_area Date: Wed, 15 May 2019 11:31:56 +0100 [thread overview] Message-ID: <a59d8d2e-0858-dc9c-466e-860657727698@arm.com> (raw) Message-ID: <20190515103156.g7QkgKs8d43DyxlYVr5A7ogANolabV1JCawxy106VHc@z> (raw) In-Reply-To: <c58b5000-623d-766e-eba8-a4df1fbe1a44@gmail.com> Hi Andrii, On 15/05/2019 10:04, Andrii Anisov wrote: > > > On 14.05.19 16:49, Julien Grall wrote: >> You have to keep in mind that existing OS have to run on newer Xen without any >> modification. > > As I just written to Jan, it is one more reason to keep those interfaces living > in parallel and do not mix their implementation. There are actually no good reason for a guest to register via the two interfaces at the same time. The more we want to encourage the OS developer to switch to the new interface. I also provided in my previous e-mails way to make the two working together without much trouble. > >> The existing hypercall allows you to: >> 1) De-register an interface using the value 0. > > My current implementation can easily be updated with the same behavior. > >> 2) Replacing a current existing interface > >> You probably can't use 2) for a bootloader -> kernel handover because we are >> dealing with guest virtual address. There is an high chance the virtual >> address space layout is going to be different or even turning off MMU for a >> bit (done on Arm). So you have to use 1) otherwise you might write in a random >> place in memory. > > This definitely not the way to handle transitions between systems in a guest > domain. > >> I am not entirely sure whether there are actual value for 2). The only reason >> I can think of is if you want to move around the runstate in your virtual >> address space. But that's sounds a bit weird at least on Arm. >> For the new hypercall, I think we at least want 1) (with a magic value TBD). > > The magic value 0x0 can easily be introduced. 0x0 is not an option. It could be a valid physical address. We need a value that cannot be used by anyone. > >> 2) might be helpful in the case the bootloader didn't do the right thing or >> we are using Kexec to boot a new kernel. This would also be safer as physical >> address could be excluded more easily. > > But the new system have to get some knowledge about the previous phys addr is > reserved (used by hypervisor), and do not use it prior to registering new > runstate area. > Providing such a knowledge is something (e.g.) the bootloader should take care > of. But, IMO, it is better to require from (e.g.) the bootloader to unregister > its runstate area prior to switching to the new system. Well, if a bootloader keep some part in memory (such as for handling runtime services), it will usually mark those pages are reserved. So it can't be used by the kernel. But here, the point is it would not be difficult to handle 2). So why would you try to forbid it? 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-15 10:32 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 2019-05-14 9:58 ` [Xen-devel] " 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 [this message] 2019-05-15 10:31 ` 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=a59d8d2e-0858-dc9c-466e-860657727698@arm.com \ --to=julien.grall@arm.com \ --cc=George.Dunlap@eu.citrix.com \ --cc=Ian.Jackson@eu.citrix.com \ --cc=JBeulich@suse.com \ --cc=andrew.cooper3@citrix.com \ --cc=andrii.anisov@gmail.com \ --cc=andrii_anisov@epam.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.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: linkBe 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).