Re: [RFC PATCH] xen/arm: Add emulation of Debug Data Transfer Registers

[Julien Grall <julien@xxxxxxx>]

Hi Stefano,

On 05/12/2023 23:21, Stefano Stabellini wrote:
> On Tue, 5 Dec 2023, Julien Grall wrote:
> > I agree that crashing a guest is bad, but is lying to the domain really
> > better? The consequence here is not that bad and hopefully it would be fairly
> > easy to find. But this is not always the case. So I definitely would place a
> > half-backed emulation more severe than a guest crash.
>
> I see where Julien is coming from, but I would go with option two:
> "emulate DCC the same way as KVM". That's because I don't think we can
> get away with crashing the guest in all cases. Although the issue came
> up with a Linux guest, it could have been triggered by a proprietary
> operating system that we cannot change, and I think Xen should support
> running unmodified operating systems.
>
> If we go with a "half-backed emulation" solution, as Julien wrote, then
> it is better to be more similar to other hypervisors, that's why I chose
> option two instead of option three.
>
> But at the same time I recognize the validity of Julien's words and it
> makes me wonder if we should have a KCONFIG option or command line
> option to switch the Xen behavior. We could use it to gate all the
> "half-backed emulation" we do for compatibility.  Something like:
>
> config PARTIAL_EMULATION
>      bool "Partial Emulation"
>      ---help---
>       
>      Enables partial, not spec compliant, emulation of certain register
>      interfaces (e.g DCC UART) for guest compatibility. If you disable
>      this option, Xen will crash the guest if the guest tries to access
>      interfaces not fully emulated or virtualized.
>
>      If you enable this option, the guest might misbehave due to non-spec
>      compliant emulation done by Xen.
As I wrote to Ayan on Matrix today, I am not in favor of the emulation. 
Yet, I am not going to oppose (as in Nack it) if the other maintainers 
agree with it.
The KConfig would be nice, the question is whether we want to (security) 
support such configuration? E.g. could this potentially introduce a 
security issue in the guest?
Regarding the  emulation itself, I actually prefer 3 because at least 
the Linux drivers will be able to bail out rather than trying to use them.
Cheers,

--
Julien Grall