|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])
Hi Stefano, On 01/12/16 21:33, Stefano Stabellini wrote: On Thu, 1 Dec 2016, Julien Grall wrote: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).I am not thinking about SBSA compliant OSes, that is the easy case :-)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.Nobody wants to bring QEMU into Xen. To be pedantic we would be bringing QEMU into xen.git, not into "Xen", but we don't want that either. Of course, any addition would need to be well justified, but at the same time, I don't think we can rule out any emulator a priori. We'll have to evaluate the issue on a case by case basis. As usual, it is going to be a trade-off between complexity, maintainability and use cases that it enables. Everybody dislike QEMU on Xen on x86, but it enabled Windows XP virtual machines back in the day. I might disagree with the way it was done, but I wonder what would be of the Xen Project today if those emullators hadn't been added in 2005. Of course the fewer emulators, the better. I wouldn't accept an IDE emulator in Xen on ARM today for example. However sometimes they are unavoidable, that's why it is important to provide a safe execution environment for them (meaning: not in Xen at EL2). Today it is pretty much the same thing to add an emulator in the hypervisor or in QEMU on x86. Somebody has to maintain the code no matter where it lives and provide security support for it. Every QEMU vulnerability ends up becoming a Xen vulnerability. In all honesty, it is better to introduce them in QEMU so that at least the few people that use stubdoms are less affected. In the future it is going to be similar to introduce new emulators in xen.git at EL0/1 or in QEMU running unprivileged in Dom0. This is to say that having emulators out of Xen (or out of xen.git) is not necessarily an improvement if they are still able to do exactly the same things, such as mapping any random page in memory. We have to factor in our decision that QEMU is been used by many people, which mean the code should be more exercised. In the case of Xen, some emulator may be used by very few people (think about TEE or a specific UART). I would require more unit tests (maybe in XTF) when a new emulator is added. Allowing us to check if the emulator is still functional. 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).I was suggesting to kill two birds with one stone and just do PL011 for DomUs (disabled by default, of course). Instead, you would keep the two use cases separate? PL011 for VM spec guests and vuart for baremetal apps? We have to keep those use cases separated. We already went in lengthly discussion and you agreed on it. Anyway, I will summarize here. In the case of bare metal application, the guest will use the host memory layout as the hypervisor would be used as an abstraction. You cannot assume if there will be a space in the layout for the PL011. Further, this guest will have a driver for the host UART and not the PL011. I expect the guest will mainly use the UART for logging, and this is very easy to expose the vuart without much change. That's an option, but we would still need to feed back the logs to xenconsoled. Agreed. How would you export the vuart in the VM config file? I am asking because I think it would be simpler to have a single: pl011=1/0, or uart="pl011" rather than a vuart option that has a different meaning on different platforms, because it is supposed to match the physical UART present. I would expect the vuart to be automatically exposed when use the host memory layout. So pl011=1/0 would be fine by me. 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 |