* [PATCH] docs/arm64: update the documention for loading XSM support @ 2016-04-14 17:06 fu.wei 2016-04-20 11:27 ` Julien Grall 0 siblings, 1 reply; 3+ messages in thread From: fu.wei @ 2016-04-14 17:06 UTC (permalink / raw) To: xen-devel, julien.grall, sstabellini, dgdegra, konrad.wilk, ian.jackson, jbeulich, keir, tim, xen-devel Cc: jcm, Fu Wei, leif.lindholm, linaro-uefi From: Fu Wei <fu.wei@linaro.org> This patch updates the documention for loading XSM by the module which lacks a specific compatible string. This mechanism has been added by the commit ca32012341f3de7d3975407fb963e6028f0d0c8b Signed-off-by: Fu Wei <fu.wei@linaro.org> --- docs/misc/arm/device-tree/booting.txt | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt index ad98bf3..f45a9c4 100644 --- a/docs/misc/arm/device-tree/booting.txt +++ b/docs/misc/arm/device-tree/booting.txt @@ -24,10 +24,19 @@ Each node contains the following properties: string (which must always be present). Xen will assume that the first module which lacks a more - specific compatible string is a "multiboot,kernel" and that - the second such is a "multiboot,ramdisk". Any subsequent - modules which lack a specific compatiblity string will not - receive any special treatment. + specific compatible string is a "multiboot,kernel". Xen will + detect the XSM magic from the second module which lacks of + a specific compatiblity string: + - if it's XSM, Xen will assume that the second such is a + "xen,xsm-policy". and also assume user won't load ramdisk; + - if it's not XSM, Xen will assume that the second such is a + "multiboot,ramdisk". + So if user want to load ramdisk without a specific compatiblity, + it must be the 2nd one. + Xen will also detect the XSM Magic for the following modules + which lack of a specific compatiblity, and assume that the module + is a "xen,xsm-policy" or "multiboot,module", according to the + result of detection. Xen 4.4 supported a different set of legacy compatible strings which remain supported such that systems supporting both 4.4 -- 2.5.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] docs/arm64: update the documention for loading XSM support 2016-04-14 17:06 [PATCH] docs/arm64: update the documention for loading XSM support fu.wei @ 2016-04-20 11:27 ` Julien Grall 2016-04-21 11:16 ` Fu Wei 0 siblings, 1 reply; 3+ messages in thread From: Julien Grall @ 2016-04-20 11:27 UTC (permalink / raw) To: fu.wei, xen-devel, sstabellini, dgdegra, konrad.wilk, ian.jackson, jbeulich, keir, tim, xen-devel Cc: jcm, leif.lindholm, linaro-uefi Hello Fu Wei, On 14/04/16 18:06, fu.wei@linaro.org wrote: > From: Fu Wei <fu.wei@linaro.org> > > This patch updates the documention for loading XSM by the module which > lacks a specific compatible string. s/documention/documentation/ s/which/that/ The sentence is not clear to me. I would rephrase: "This patch updates the documentation for allowing detection of an XSM module that lacks a specific compatible string". > This mechanism has been added by the > commit ca32012341f3de7d3975407fb963e6028f0d0c8b Missing full stop. > > Signed-off-by: Fu Wei <fu.wei@linaro.org> > --- > docs/misc/arm/device-tree/booting.txt | 17 +++++++++++++---- > 1 file changed, 13 insertions(+), 4 deletions(-) > > diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt > index ad98bf3..f45a9c4 100644 > --- a/docs/misc/arm/device-tree/booting.txt > +++ b/docs/misc/arm/device-tree/booting.txt > @@ -24,10 +24,19 @@ Each node contains the following properties: > string (which must always be present). > > Xen will assume that the first module which lacks a more > - specific compatible string is a "multiboot,kernel" and that > - the second such is a "multiboot,ramdisk". Any subsequent > - modules which lack a specific compatiblity string will not > - receive any special treatment. > + specific compatible string is a "multiboot,kernel". Xen will > + detect the XSM magic from the second module which lacks of > + a specific compatiblity string: s/compatiblity/ The sentence is not clear. You could read as: "Xen will check all the modules from the second module that lacks a specific compatible string". I.e Xen will do the XSM magic check even if the module has a specific compatible string. I would instead say "For the second module that lacks a specific compatible string, Xen will check if the module is a XSM policy: > + - if it's XSM, Xen will assume that the second such is a "second such" is not clear. > + "xen,xsm-policy". and also assume user won't load ramdisk; s/.// I would drop the rest of the sentence after "and". > + - if it's not XSM, Xen will assume that the second such is a "second such" is not clear. > + "multiboot,ramdisk". > + So if user want to load ramdisk without a specific compatiblity, s/user/the user/ s/compatiblity/compatibility/ However this is a documentation for the user. So I would say "This means that if the ramdisk module is present and does not have a the compatible string "multiboot,ramdisk", then it must be always the second module". > + it must be the 2nd one. > + Xen will also detect the XSM Magic for the following modules > + which lack of a specific compatiblity, and assume that the module s/compatiblity/compatibility/ > + is a "xen,xsm-policy" or "multiboot,module", according to the > + result of detection. s/or/or a/ s/detection/the detection/ I would also invert the two paragraphs. I.e inverting "So if user.." and "Xen will...". Can you also mention that this behavior was introduced by Xen 4.7. I.e Xen 4.6 (and downwards) still requires the module to have the compatible string "xen,xsm-policy" and therefore XSM won't work with GRUB. The latter bits may need to be documented in GRUB. > > Xen 4.4 supported a different set of legacy compatible strings > which remain supported such that systems supporting both 4.4 > Regards, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] docs/arm64: update the documention for loading XSM support 2016-04-20 11:27 ` Julien Grall @ 2016-04-21 11:16 ` Fu Wei 0 siblings, 0 replies; 3+ messages in thread From: Fu Wei @ 2016-04-21 11:16 UTC (permalink / raw) To: Julien Grall Cc: xen-devel, keir, Tim Deegan, ian.jackson, Leif Lindholm, xen-devel, sstabellini, Jan Beulich, Linaro UEFI Mailman List, Daniel De Graaf, Jon Masters Hi Julien, Great thanks for your review and suggestion. I have taken almost all your suggestion, but did some modification, please have a look: http://lists.xen.org/archives/html/xen-devel/2016-04/msg02637.html Thanks for your help! :-) On 20 April 2016 at 19:27, Julien Grall <julien.grall@arm.com> wrote: > Hello Fu Wei, > > On 14/04/16 18:06, fu.wei@linaro.org wrote: >> >> From: Fu Wei <fu.wei@linaro.org> >> >> This patch updates the documention for loading XSM by the module which > >> lacks a specific compatible string. > > s/documention/documentation/ > s/which/that/ > > The sentence is not clear to me. I would rephrase: > > "This patch updates the documentation for allowing detection of an XSM > module that lacks a specific compatible string". > >> This mechanism has been added by the >> >> commit ca32012341f3de7d3975407fb963e6028f0d0c8b > > > Missing full stop. > >> >> Signed-off-by: Fu Wei <fu.wei@linaro.org> >> --- >> docs/misc/arm/device-tree/booting.txt | 17 +++++++++++++---- >> 1 file changed, 13 insertions(+), 4 deletions(-) >> >> diff --git a/docs/misc/arm/device-tree/booting.txt >> b/docs/misc/arm/device-tree/booting.txt >> index ad98bf3..f45a9c4 100644 >> --- a/docs/misc/arm/device-tree/booting.txt >> +++ b/docs/misc/arm/device-tree/booting.txt >> @@ -24,10 +24,19 @@ Each node contains the following properties: >> string (which must always be present). >> >> Xen will assume that the first module which lacks a more >> - specific compatible string is a "multiboot,kernel" and that >> - the second such is a "multiboot,ramdisk". Any subsequent >> - modules which lack a specific compatiblity string will not >> - receive any special treatment. >> + specific compatible string is a "multiboot,kernel". Xen will >> + detect the XSM magic from the second module which lacks of >> + a specific compatiblity string: > > > s/compatiblity/ > > The sentence is not clear. You could read as: "Xen will check all the > modules from the second module that lacks a specific compatible string". > > I.e Xen will do the XSM magic check even if the module has a specific > compatible string. > > I would instead say "For the second module that lacks a specific compatible > string, Xen will check if the module is a XSM policy: > >> + - if it's XSM, Xen will assume that the second such is a > > > "second such" is not clear. > >> + "xen,xsm-policy". and also assume user won't load ramdisk; > > > s/.// > > I would drop the rest of the sentence after "and". > >> + - if it's not XSM, Xen will assume that the second such is a > > > "second such" is not clear. > >> + "multiboot,ramdisk". >> + So if user want to load ramdisk without a specific compatiblity, > > > s/user/the user/ > s/compatiblity/compatibility/ > > However this is a documentation for the user. So I would say "This means > that if the ramdisk module is present and does not have a the compatible > string "multiboot,ramdisk", then it must be always the second module". > >> + it must be the 2nd one. >> + Xen will also detect the XSM Magic for the following modules >> + which lack of a specific compatiblity, and assume that the module > > > s/compatiblity/compatibility/ > >> + is a "xen,xsm-policy" or "multiboot,module", according to the >> + result of detection. > > > s/or/or a/ > s/detection/the detection/ > > I would also invert the two paragraphs. I.e inverting "So if user.." and > "Xen will...". > > Can you also mention that this behavior was introduced by Xen 4.7. I.e Xen > 4.6 (and downwards) still requires the module to have the compatible string > "xen,xsm-policy" and therefore XSM won't work with GRUB. > > The latter bits may need to be documented in GRUB. > >> >> Xen 4.4 supported a different set of legacy compatible strings >> which remain supported such that systems supporting both 4.4 >> > > Regards, > > -- > Julien Grall -- Best regards, Fu Wei Software Engineer Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch Ph: +86 21 61221326(direct) Ph: +86 186 2020 4684 (mobile) Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-04-21 11:16 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-04-14 17:06 [PATCH] docs/arm64: update the documention for loading XSM support fu.wei 2016-04-20 11:27 ` Julien Grall 2016-04-21 11:16 ` Fu Wei
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).