[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/9] xen/x86: PVH Dom0 fixes and fallout adjustments

  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 15 Sep 2021 10:29:12 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2YQi9jhheTBMVlHNg08LfTgwAJJiCRcBKae449KfxBk=; b=Hi6xPT9QK1XfTKwlte+h/B2i7CJgJ4I6EoAa5E31KxPJ+aY6BWFQ2DentiABLPk8Fmt4hU22eDB8w8CaHl/ODwJfWBhN9OrlAQGMIhVZuS7tSGDa4YvwHFZDS+8hoGa4zbPdLpoLT148ENlTV6DroaMKIvnx9q9nqBgPpGJcXTRgDoT0h9Ry9QKbQzkZUvXNpBUpegDWwTbQ1bik2qiat4GXrElx3s+VaKyg+vzfYPkBR9DpGigKW8AimFCCKLU+W7C2afiuw66fcRxO44w+4dTIRWJgTKHRFzYk9wQiAz/vAqnKRkD/Z8OKD9clqoT+XliyUVt3BCaR3LKFTpAaOg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BKR3KyojnGCablw2P/AcNxOpYnZXAK6fS6jSoWj6MFpypqrjMDe1nO4cs0n1KZva92g/ib3HoxyCeB54y/40a23EPS42LxZtayOQZdnscPN4RSSEHs8QaqzR2WQY6wu5Xor1jKw7KwqkA2Y2LPjfjXORxMZS+bZbfJmlU6PSNnKbq9G+RE4wKpIgilVHAk3DPPzKT4U7bDrDIotvqxRwtG/fnBtHKsmy2qCIp3O/Ig9eHTcso9Ji9TV/9Mto/GYGZa2O7QLDTXSIYsy9uu1sRunEUqoVNgJUOEk2r+K1ykAWkMKhwonHbw6qFXDBS+JgFJ3RqahAYiehvg0WvkFrVA==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: Juergen Gross <jgross@xxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, lkml <linux-kernel@xxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 15 Sep 2021 08:29:29 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 14.09.2021 18:27, Roger Pau Monné wrote:
> On Tue, Sep 14, 2021 at 05:13:52PM +0200, Jan Beulich wrote:
>> On 14.09.2021 14:41, Roger Pau Monné wrote:
>>> On Tue, Sep 14, 2021 at 01:58:29PM +0200, Jan Beulich wrote:
>>>> On 14.09.2021 13:15, Roger Pau Monné wrote:
>>>>> On Tue, Sep 14, 2021 at 11:03:23AM +0200, Jan Beulich wrote:
>>>>>> On 14.09.2021 10:32, Roger Pau Monné wrote:
>>>>>>> On Tue, Sep 07, 2021 at 12:04:34PM +0200, Jan Beulich wrote:
>>>>>>>> 2) Dom0, unlike in the PV case, cannot access the screen (to use as a
>>>>>>>>    console) when in a non-default mode (i.e. not 80x25 text), as the
>>>>>>>>    necessary information (in particular about VESA-bases LFB modes) is
>>>>>>>>    not communicated. On the hypervisor side this looks like deliberate
>>>>>>>>    behavior, but it is unclear to me what the intentions were towards
>>>>>>>>    an alternative model. (X may be able to access the screen depending
>>>>>>>>    on whether it has a suitable driver besides the presently unusable
>>>>>>>>    /dev/fb<N> based one.)
>>>>>>> I had to admit most of my boxes are headless servers, albeit I have
>>>>>>> one NUC I can use to test gfx stuff, so I don't really use gfx output
>>>>>>> with Xen.
>>>>>>> As I understand such information is fetched from the BIOS and passed
>>>>>>> into Xen, which should then hand it over to the dom0 kernel?
>>>>>> That's how PV Dom0 learns of the information, yes. See
>>>>>> fill_console_start_info(). (I'm in the process of eliminating the
>>>>>> need for some of the "fetch from BIOS" in Xen right now, but that's
>>>>>> not going to get us as far as being able to delete that code, no
>>>>>> matter how much in particular Andrew would like that to happen.)
>>>>>>> I guess the only way for Linux dom0 kernel to fetch that information
>>>>>>> would be to emulate the BIOS or drop into realmode and issue the BIOS
>>>>>>> calls?
>>>>>> Native Linux gets this information passed from the boot loader, I think
>>>>>> (except in the EFI case, as per below).
>>>>>>> Is that an issue on UEFI also, or there dom0 can fetch the framebuffer
>>>>>>> info using the PV EFI interface?
>>>>>> There it's EFI boot services functions which can be invoked before
>>>>>> leaving boot services (in the native case). Aiui the PVH entry point
>>>>>> lives logically past any EFI boot services interaction, and hence
>>>>>> using them is not an option (if there was EFI firmware present in Dom0
>>>>>> in the first place, which I consider difficult all by itself - this
>>>>>> can't be the physical system's firmware, but I also don't see where
>>>>>> virtual firmware would be taken from).
>>>>>> There is no PV EFI interface to obtain video information. With the
>>>>>> needed information getting passed via start_info, PV has no need for
>>>>>> such, and I would be hesitant to add a fundamentally redundant
>>>>>> interface for PVH. The more that the information needed isn't EFI-
>>>>>> specific at all.
>>>>> I think our only option is to expand the HVM start info information to
>>>>> convey that data from Xen into dom0.
>>>> PHV doesn't use the ordinary start_info, does it?
>>> No, it's HVM start info as described in:
>>> xen/include/public/arch-x86/hvm/start_info.h
>>> We have already extended it once to add a memory map, we could extend
>>> it another time to add the video information.
>> Okay, I'll try to make a(nother) patch along these lines. Since there's
>> a DomU counterpart in PV's start_info - where does that information get
>> passed for PVH? (I'm mainly wondering whether there's another approach
>> to consider.)
> We don't pass the video information at all for PVH, neither in domU or
> dom0 modes if that's what you mean. Not sure what video information we
> could pass for domU anyway, as that would be a PV framebuffer that
> would need setup ATM. Maybe we could at some point provide some kind
> of emulated or passed through card.
> The information contained in start_info that's needed for PVH is
> passed using hvm params, just like it's done for plain HVM guests.

This is what I was referring to; I'm sorry for having been unclear.
It's no video _mode_ information, but information on hot to get at
the console.

> We
> could pass the video information in a hvm param I guess, but it would
> require stealing guest memory to store it (and mark as reserved in
> the memory map). Not sure that's better than expanding HVM start info.

I don't think it would be; a param doesn't seem a good fit here,
and I have to admit I'm not even convinced its a good fit for
xenstore and console coordinates (that's fine for HVM; the only
reason I can see for PVH to use the same is the expectation of
the line between both to become increasingly blurred).

> Maybe there's another hypercall interface I'm missing we could use to
> propagate that information to dom0?

I don't think there is; if anything we'd have to add something.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.