[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [RFC PATCH] xen/arm: Add emulation of Debug Data Transfer Registers
On 05/12/2023 09:28, Michal Orzel wrote: Hi Julien, On 04/12/2023 20:55, Julien Grall wrote:On 04/12/2023 13:02, Ayan Kumar Halder wrote:On 04/12/2023 10:31, Julien Grall wrote:Hi Ayan,Hi Julien,On 01/12/2023 18:50, Ayan Kumar Halder wrote:Currently if user enables HVC_DCC config option in Linux, it invokes access to debug data transfer registers (ie DBGDTRTX_EL0 on arm64, DBGDTRTXINT on arm32). As these registers are not emulated, Xen injects an undefined exception to the guest. And Linux crashes.I am missing some data points here to be able to say whether I would be ok with emulating the registers. So some questions: * As you wrote below, HVC_DCC will return -ENODEV after this emulation. So may I ask what's the use case to enable it? (e.g. is there a distro turning this on?)I am not aware of any distro using (or not using) this feature. This issue came to light during our internal testing, when HVC_DCC was enabled to use the debug console. When Linux runs without Xen, then we could observe the logs on the debug console. When Linux was running as a VM, it crashed. My intention here was to do the bare minimum emulation so that the crash could be avoided.This reminds me a bit the discussion around "xen/arm64: Decode ldr/str post increment operations". I don't want Xen to contain half-backed emulation just to please an OS in certain configuration that doesn't seem to be often used. Also, AFAICT, KVM is in the same situation...Well, KVM is not in the same situation. It emulates all DCC regs as RAZ/WI, so there will be no fault on an attempt to access the DCC. Does this mean a guest will think the JTAG is availabe? In general, I think that if a register is not optional and does not depend on other register to be checked first (e.g. a feature/control register we emulate), which implies that it is fully ok for a guest to access it directly - we should at least try to do something not to crash a guest. This is where we have opposing opinion. I view crashing a guest better than providing a wrong emulation because it gives a clear signal that the register they are trying to access will not function properly. We had this exact same discussion a few years ago when Linux started to access GIC*_ACTIVER registers. I know that Stefano was for emulating them as RAZ but this had consequences on the domain side (Linux sometimes need to read them). We settled on printing a warning which is not great but better than claiming we properly emulate the register. I agree that this feature is not widely used. In fact I can only find it implemented in Linux and U-BOOT and the issue I found in DBGDSCRINT (no access from EL0, even though we emulate REXT.UDCCdis as 0) only proves that. At the same time, it does not cost us much to add this trivial support. See above. If we provide an (even basic) emulation, we need to make sure it is correct and doesn't have a side effect on the guest. If we can't guarantee that (e.g. like for set/way when a device is assigned), then the best course of action is to crash the domain. AFAICT, the proposed emulation would be ok. But I want to make clear that I would not generally be ok with this approach and the decision would need to be on the case by case basis. Cheers, -- Julien Grall
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |