|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])
On 01/12/16 02:07, Stefano Stabellini wrote: On Fri, 25 Nov 2016, Julien Grall wrote:Hi Stefano, Hi, On 23/11/16 19:55, Stefano Stabellini wrote:Actually I am thinking that the default values should be in the emulators themselves. After all they are the part of the code that knows more about vuarts.Can you expand what you mean by emulator? I was never expecting to have a fully emulated UART exposed to the guest (i.e read/write character support) except for a PL011.Once we start having emulators, it is possible that we'll end up with more than one. For example, we introduce the PL011 now, then in a couple of years somebody wants to add ns16550 because it is the only one that Windows 2019 supports. I am assuming that one way or another they'll run in a low privilege mode (see other recent threads). Well, if this Windows is meant to run on SBSA complaint server, it will have to support either PL011 or SBSA (a subset of PL011). If we are going to allow more kind of UART? Why don't we have a disk emulator in Xen? How about a network emulator? Overall Windows 2019 may not have PV drivers for the network and disk. I really think we have to draw a line of what we are supporting. The PL011 is mandatory by a specification. If the guest is not compliant then it will have to use either PV drivers or having a device assigned. The addition of a new emulator in upstream would need to be justified. I don't want to end up bringing QEMU in Xen. The current vuart (see xen/arch/arm/vuart.c) is very simple but require someone to configure it. For DOM0, this is configured by the serial driver. For guest we need someone doing the same.I understand. For clarity, I'll call "PL011 emulator" the one that will end up being used for DomUs, which might be based on, or different from, xen/arch/arm/vuart.c. It doesn't exist yet. The PL011 emulator should have default values for everything. Some of these values could be configured by libxl, but none should be required to be configured by libxl. The last thing we want is to disseminate numbers and addresses in libxl. One of these parameters could be the MMIO address, but it is just an example, we don't necessarily need to support changing it. It could be a decent feature to have but I don't think is important if we'll support configurable memory layouts soon. This is what I have been suggested from the beginning :).But in the case of baremetal application, we want to be able to do logging only (i.e not reading). They will have a driver for the host UART. It would be pointless and potentially difficult to emulate a full UART here. This is where vuart come in place (see the use case mentioned by Edgar). So the toolstack would pass down all the info provided by the users to Xen. Xen would start the appropriate emulator, initializing anything not specifically configured by libxl to default values. No need for long lists of defaults in libxl.If so, you will end up people asking to implement each of their UART (8250, exynos, pl011...) in the toolstack. A user would have to pay attention whether this model is supported or not by their toolstack.It is up to the maintainers to decide how many and which vuart should be configurable. libxl would have the capability of listing supported models of vuarts. Today libxl already does that for nics and vgas.As we discussed recently, the goal of exposing the vuart is to let the guest write data not read without having to bring a full PV drivers. Supporting multiple fully emulated UARTs would be very similarly to incorporate piece of QEMU code within Xen. I think we both well know what it means in term of security. We have to emulate a PL011 because this is part of the VM spec. If you think that more kind of UART have to be emulated, then I would like to see real use case as nobody stepped up for that on the ML so far.Unfortunately we have to expect that the number of requests for emulators will only increase going forward. We need to have a proper low privilege mode to run them in, to avoid security issues in Xen. See my answer above. Lastly, the pl011 emulation needs to be easily enabled by any user without requiring a knowledge on the guest memory layout (which is not stable BTW). By default the layout is static, so what's the point to let the user configuring it?This is my reasoning: people that request a vuart explicitly in the VM config file are people that are configuring an embedded system with non-Linux OSes because all others should be able to use the PV console effectively. In that case, to setup the system with the minimum amount of configuration and efforts, they might want to emulate one of the UARTs supported by their non-Linux OSes. The PL011 is pretty widespread, so it could be a good choice. Additionally they know the memory layout of all their VMs, so they can easily pick an unused address and configure it both in the VM config file and in their non-Linux OS.Their non-Linux OSes will already need to be aware of the guest memory layout because it is fully static. They will use either device-tree/acpi or hardcoded the layout. In both case, could you explain why they would want to configure the base address of the UART? It looks like to me it is more burden to chose the address. They would be fine to use the one in the static memory layout. If they want a dynamic memory layout (host or custom [1]). Then it needs to be fully defined separately. I am not in favor of having a layout that can be half-static, half-dynamic as you are currently suggesting. Note that I know this is currently the case for iomem parameters, but I found this ugly and there was no better solution. Let's not continue that way.I see, I was exactly thinking of iomem as a model :-) My thinking is that some users might have half-hacked Xen and half-hacked the guest OS to make their ideas of memory match. This is very fragile because you cannot control where the memory banks, gic regions are residing. Hence why I would like to push towards a fully dynamic layout. Naively, I am thinking that the ability to specify the uart address would help, but maybe I am wrong. I do agree that a fully configurable memory layout solves most problems. Regards, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |