xen/arch/arm/arm64/vsysreg.c | 49 +++++++++++++++++++ xen/arch/arm/cpufeature.c | 67 ++++++++++++++++++++++++++ xen/arch/arm/traps.c | 7 ++- xen/arch/arm/vcpreg.c | 73 +++++++++++++++++++++++++++++ xen/include/asm-arm/arm64/hsr.h | 37 +++++++++++++++ xen/include/asm-arm/arm64/sysregs.h | 22 +++++++++ xen/include/asm-arm/cpregs.h | 10 ++++ xen/include/asm-arm/cpufeature.h | 63 +++++++++++++++++++++---- xen/include/asm-arm/perfc_defn.h | 1 + xen/include/asm-arm/traps.h | 1 + 10 files changed, 321 insertions(+), 9 deletions(-)
The goal of this serie is to emulate coprocessor ID registers so that Xen only publish to guest features that are supported by Xen and can actually be used by guests. One practical example where this is required are SVE support which is forbidden by Xen as it is not supported, but if Linux is compiled with it, it will crash on boot. An other one is AMU which is also forbidden by Xen but one Linux compiled with it would crash if the platform supports it. To be able to emulate the coprocessor registers defining what features are supported by the hardware, the TID3 bit of HCR must be disabled and Xen must emulated the values of those registers when an exception is catched when a guest is accessing it. This serie is first creating a guest cpuinfo structure which will contain the values that we want to publish to the guests and then provides the proper emulationg for those registers when Xen is getting an exception due to an access to any of those registers. This is a first simple implementation to solve the problem and the way to define the values that we provide to guests and which features are disabled will be in a future patchset enhance so that we could decide per guest what can be used or not and depending on this deduce the bits to activate in HCR and the values that we must publish on ID registers. Bertrand Marquis (7): xen/arm: Add ID registers and complete cpufinfo xen/arm: Add arm64 ID registers definitions xen/arm: create a cpuinfo structure for guest xen/arm: Add handler for ID registers on arm64 xen/arm: Add handler for cp15 ID registers xen/arm: Add CP10 exception support to handle VMFR xen/arm: Activate TID3 in HCR_EL2 xen/arch/arm/arm64/vsysreg.c | 49 +++++++++++++++++++ xen/arch/arm/cpufeature.c | 67 ++++++++++++++++++++++++++ xen/arch/arm/traps.c | 7 ++- xen/arch/arm/vcpreg.c | 73 +++++++++++++++++++++++++++++ xen/include/asm-arm/arm64/hsr.h | 37 +++++++++++++++ xen/include/asm-arm/arm64/sysregs.h | 22 +++++++++ xen/include/asm-arm/cpregs.h | 10 ++++ xen/include/asm-arm/cpufeature.h | 63 +++++++++++++++++++++---- xen/include/asm-arm/perfc_defn.h | 1 + xen/include/asm-arm/traps.h | 1 + 10 files changed, 321 insertions(+), 9 deletions(-) -- 2.17.1
On 26/11/2020 15:51, Bertrand Marquis wrote: > The goal of this serie is to emulate coprocessor ID registers so that > Xen only publish to guest features that are supported by Xen and can > actually be used by guests. > One practical example where this is required are SVE support which is > forbidden by Xen as it is not supported, but if Linux is compiled with > it, it will crash on boot. An other one is AMU which is also forbidden > by Xen but one Linux compiled with it would crash if the platform > supports it. > > To be able to emulate the coprocessor registers defining what features > are supported by the hardware, the TID3 bit of HCR must be disabled and > Xen must emulated the values of those registers when an exception is > catched when a guest is accessing it. > > This serie is first creating a guest cpuinfo structure which will > contain the values that we want to publish to the guests and then > provides the proper emulationg for those registers when Xen is getting > an exception due to an access to any of those registers. > > This is a first simple implementation to solve the problem and the way > to define the values that we provide to guests and which features are > disabled will be in a future patchset enhance so that we could decide > per guest what can be used or not and depending on this deduce the bits > to activate in HCR and the values that we must publish on ID registers. > > Bertrand Marquis (7): > xen/arm: Add ID registers and complete cpufinfo > xen/arm: Add arm64 ID registers definitions > xen/arm: create a cpuinfo structure for guest > xen/arm: Add handler for ID registers on arm64 > xen/arm: Add handler for cp15 ID registers > xen/arm: Add CP10 exception support to handle VMFR > xen/arm: Activate TID3 in HCR_EL2 CI found an ARM randconfig failure against this series. https://gitlab.com/xen-project/patchew/xen/-/pipelines/221798884 I have admit that I can't spot an obvious connection so it might be collateral damage from elsewhere, but does need looking at irrespective. ~Andrew (in lieu of a real CI robot).
Hi Andrew, > On 27 Nov 2020, at 20:07, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > > On 26/11/2020 15:51, Bertrand Marquis wrote: >> The goal of this serie is to emulate coprocessor ID registers so that >> Xen only publish to guest features that are supported by Xen and can >> actually be used by guests. >> One practical example where this is required are SVE support which is >> forbidden by Xen as it is not supported, but if Linux is compiled with >> it, it will crash on boot. An other one is AMU which is also forbidden >> by Xen but one Linux compiled with it would crash if the platform >> supports it. >> >> To be able to emulate the coprocessor registers defining what features >> are supported by the hardware, the TID3 bit of HCR must be disabled and >> Xen must emulated the values of those registers when an exception is >> catched when a guest is accessing it. >> >> This serie is first creating a guest cpuinfo structure which will >> contain the values that we want to publish to the guests and then >> provides the proper emulationg for those registers when Xen is getting >> an exception due to an access to any of those registers. >> >> This is a first simple implementation to solve the problem and the way >> to define the values that we provide to guests and which features are >> disabled will be in a future patchset enhance so that we could decide >> per guest what can be used or not and depending on this deduce the bits >> to activate in HCR and the values that we must publish on ID registers. >> >> Bertrand Marquis (7): >> xen/arm: Add ID registers and complete cpufinfo >> xen/arm: Add arm64 ID registers definitions >> xen/arm: create a cpuinfo structure for guest >> xen/arm: Add handler for ID registers on arm64 >> xen/arm: Add handler for cp15 ID registers >> xen/arm: Add CP10 exception support to handle VMFR >> xen/arm: Activate TID3 in HCR_EL2 > > CI found an ARM randconfig failure against this series. > > https://gitlab.com/xen-project/patchew/xen/-/pipelines/221798884 > > I have admit that I can't spot an obvious connection so it might be > collateral damage from elsewhere, but does need looking at irrespective. This absolutely right, there is a bug in my code and i will send a V2 to fix it. Very nice finding, i am wondering why my tests did not point this out. Regards Bertrand > > ~Andrew (in lieu of a real CI robot).
On 30/11/2020 10:20, Bertrand Marquis wrote: > Hi Andrew, > >> On 27 Nov 2020, at 20:07, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >> >> On 26/11/2020 15:51, Bertrand Marquis wrote: >>> The goal of this serie is to emulate coprocessor ID registers so that >>> Xen only publish to guest features that are supported by Xen and can >>> actually be used by guests. >>> One practical example where this is required are SVE support which is >>> forbidden by Xen as it is not supported, but if Linux is compiled with >>> it, it will crash on boot. An other one is AMU which is also forbidden >>> by Xen but one Linux compiled with it would crash if the platform >>> supports it. >>> >>> To be able to emulate the coprocessor registers defining what features >>> are supported by the hardware, the TID3 bit of HCR must be disabled and >>> Xen must emulated the values of those registers when an exception is >>> catched when a guest is accessing it. >>> >>> This serie is first creating a guest cpuinfo structure which will >>> contain the values that we want to publish to the guests and then >>> provides the proper emulationg for those registers when Xen is getting >>> an exception due to an access to any of those registers. >>> >>> This is a first simple implementation to solve the problem and the way >>> to define the values that we provide to guests and which features are >>> disabled will be in a future patchset enhance so that we could decide >>> per guest what can be used or not and depending on this deduce the bits >>> to activate in HCR and the values that we must publish on ID registers. >>> >>> Bertrand Marquis (7): >>> xen/arm: Add ID registers and complete cpufinfo >>> xen/arm: Add arm64 ID registers definitions >>> xen/arm: create a cpuinfo structure for guest >>> xen/arm: Add handler for ID registers on arm64 >>> xen/arm: Add handler for cp15 ID registers >>> xen/arm: Add CP10 exception support to handle VMFR >>> xen/arm: Activate TID3 in HCR_EL2 >> CI found an ARM randconfig failure against this series. >> >> https://gitlab.com/xen-project/patchew/xen/-/pipelines/221798884 >> >> I have admit that I can't spot an obvious connection so it might be >> collateral damage from elsewhere, but does need looking at irrespective. > This absolutely right, there is a bug in my code and i will send a V2 to fix it. > > Very nice finding, i am wondering why my tests did not point this out. Its randconfig, so every time the test runs, it picks a new random Kconfig configuration. Sadly, it is non-deterministic, and not necessarily the fault of change the test ran against. We're probably going to have to tweak how we run these tests before the CI goes too much further. ~Andrew
Hi Andrew, > On 30 Nov 2020, at 10:36, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > > On 30/11/2020 10:20, Bertrand Marquis wrote: >> Hi Andrew, >> >>> On 27 Nov 2020, at 20:07, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >>> >>> On 26/11/2020 15:51, Bertrand Marquis wrote: >>>> The goal of this serie is to emulate coprocessor ID registers so that >>>> Xen only publish to guest features that are supported by Xen and can >>>> actually be used by guests. >>>> One practical example where this is required are SVE support which is >>>> forbidden by Xen as it is not supported, but if Linux is compiled with >>>> it, it will crash on boot. An other one is AMU which is also forbidden >>>> by Xen but one Linux compiled with it would crash if the platform >>>> supports it. >>>> >>>> To be able to emulate the coprocessor registers defining what features >>>> are supported by the hardware, the TID3 bit of HCR must be disabled and >>>> Xen must emulated the values of those registers when an exception is >>>> catched when a guest is accessing it. >>>> >>>> This serie is first creating a guest cpuinfo structure which will >>>> contain the values that we want to publish to the guests and then >>>> provides the proper emulationg for those registers when Xen is getting >>>> an exception due to an access to any of those registers. >>>> >>>> This is a first simple implementation to solve the problem and the way >>>> to define the values that we provide to guests and which features are >>>> disabled will be in a future patchset enhance so that we could decide >>>> per guest what can be used or not and depending on this deduce the bits >>>> to activate in HCR and the values that we must publish on ID registers. >>>> >>>> Bertrand Marquis (7): >>>> xen/arm: Add ID registers and complete cpufinfo >>>> xen/arm: Add arm64 ID registers definitions >>>> xen/arm: create a cpuinfo structure for guest >>>> xen/arm: Add handler for ID registers on arm64 >>>> xen/arm: Add handler for cp15 ID registers >>>> xen/arm: Add CP10 exception support to handle VMFR >>>> xen/arm: Activate TID3 in HCR_EL2 >>> CI found an ARM randconfig failure against this series. >>> >>> https://gitlab.com/xen-project/patchew/xen/-/pipelines/221798884 >>> >>> I have admit that I can't spot an obvious connection so it might be >>> collateral damage from elsewhere, but does need looking at irrespective. >> This absolutely right, there is a bug in my code and i will send a V2 to fix it. >> >> Very nice finding, i am wondering why my tests did not point this out. > > Its randconfig, so every time the test runs, it picks a new random > Kconfig configuration. This could be consider as a fuzzer testing and can be very usefull. > > Sadly, it is non-deterministic, and not necessarily the fault of change > the test ran against. We're probably going to have to tweak how we run > these tests before the CI goes too much further. Agree but in this case the error would have been triggered for any Arm configuration with the right compiler flags. Regards Bertrand
© 2016 - 2024 Red Hat, Inc.