From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fabio Fantoni Subject: Re: [PATCH 0/4] Reintroduce OVMF support Date: Wed, 16 Oct 2013 16:13:37 +0200 Message-ID: <525E9F11.6030905@m2r.biz> References: <1381855205-3329-1-git-send-email-wei.liu2@citrix.com> <525E6467.80806@m2r.biz> <20131016125122.GC16371@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20131016125122.GC16371@zion.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu Cc: ian.jackson@eu.citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org Il 16/10/2013 14:51, Wei Liu ha scritto: > On Wed, Oct 16, 2013 at 12:03:19PM +0200, Fabio Fantoni wrote: >> Il 15/10/2013 18:40, Wei Liu ha scritto: >>> This small series reintroduces OVMF support in Xen >>> >>> You can fetch working OVMF tree on: >>> git://xenbits.xen.org/people/liuw/ovmf.git master >>> >>> Working changeset that can be sticked in Config.mk is: >>> 8833370303d3bf3153760ee42760ef1b9b5c562 >>> >>> Note that VNC doesn't work properly when using OVMF, but that's not OVMF's >>> problem. This issue should be addressed in Xen and I'm working on that. >>> >>> Wei. >> Thanks for work on it, when I tested it months ago there was lot of >> problems. > Could you elaborate on the problems you're seeing? I'm aware of the VNC > not refreshing problem but that's not to be fixed in OVMF. > >> I think it would be good thing to give an eye to the links below to >> improve the hvm part: >> >> - Integrate legacy bios support inside ovmf (I saw a draft on link >> above and I not know actual progress, there was also discussion >> about it on seabios mailing list) >> http://git.infradead.org/users/dwmw2/edk2.git >> http://git.infradead.org/users/dwmw2/seabios.git >> > Hmm... I think this is orthogonal. We can get all those gravy new > features when we refresh our own tree. > > Keep in mind that we're not forking EDK2. Actually we're trying to work > closely with upstream - I fixed a upstream bug to make OVMF work with > Xen before sending the series so in fact the tree I'm presenting is just > vanilla upstream tree. > > The reason we have our own tree is that we need to have a central > location where users can pull from. Also we would test our branch to > avoid frustration. Yes I don't want to fork ovmf, just check if there is already legacy bios support on upstream, otherwise keep an eye on it. I think it is important to have both uefi and bios support in a single place in the future. > >> - Since this is a new/experimental section, it would be a better >> path to move the actual 'static' data taken from hvmloader more >> 'dynamics' or at least have theme generated from qemu. >> This would lead in turn to a better support for all the new qemu >> device/features and also to avoid eventual regressions with >> ovmf/qemu newer versions. > I don't see why OVMF would prevent you from using QEMU new device > features, but I sort of get the idea of separating hvmloader and other > firmwares. You could make an argument / request on xen-devel and ask > George to keep track of it, then we will see what we can do. > > Wei. Maybe I didn't explain myself well, I was talking about ACPI tables and all other static tables in hvmloader. I think it would be better to get these tables from OVMF/QEMU so that we don't need to update them in Xen every time something changes in new versions of OVMF/QEMU or particular devices (emulated or passthrough). I don't know if what I have in mind is feasible and correct considering my lack of knowledge about it but if I understand correctly it would get rid of many problems with new versions of qemu or with optional devices affecting such part.