[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 12/12] hw/xen: add support for Xen primary console in emulated mode
On 24/10/2023 16:49, David Woodhouse wrote: On Tue, 2023-10-24 at 16:39 +0100, Paul Durrant wrote:On 24/10/2023 16:37, David Woodhouse wrote:On Tue, 2023-10-24 at 15:20 +0100, Paul Durrant wrote:On 16/10/2023 16:19, David Woodhouse wrote:From: David Woodhouse <dwmw@xxxxxxxxxxxx> The primary console is special because the toolstack maps a page at a fixed GFN and also allocates the guest-side event channel. Add support for that in emulated mode, so that we can have a primary console. Add a *very* rudimentary stub of foriegnmem ops for emulated mode, which supports literally nothing except a single-page mapping of the console page. This might as well have been a hack in the xen_console driver, but this way at least the special-casing is kept within the Xen emulation code, and it gives us a hook for a more complete implementation if/when we ever do need one.Why can't you map the console page via the grant table like the xenstore page?I suppose we could, but I didn't really want the generic xen-console device code having any more of a special case for 'Xen emulation' than it does already by having to call xen_primary_console_create().But doesn't is save you the whole foreignmem thing? You can use the grant table for primary and secondary consoles.Yes. And I could leave the existing foreignmem thing just for the case of primary console under true Xen. It's probably not that awful a special case, in the end. Then again, I was surprised I didn't *already* have a foreignmem ops for the emulated case, and we're probably going to want to continue fleshing it out later, so I don't really mind adding it. True. We'll need it for some of the other more fun protocols like vkbd or fb. Still, I think it'd be nicer to align the xenstore and primary console code to look similar and punt the work until then :-) Paul
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |