From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fabio Fantoni Subject: Re: [PATCH 0/4] Reintroduce OVMF support Date: Thu, 17 Oct 2013 11:13:29 +0200 Message-ID: <525FAA39.60005@m2r.biz> References: <1381855205-3329-1-git-send-email-wei.liu2@citrix.com> <525E6467.80806@m2r.biz> <20131016125122.GC16371@zion.uk.xensource.com> <525E9F11.6030905@m2r.biz> <20131016150002.GH16371@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: <20131016150002.GH16371@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 17:00, Wei Liu ha scritto: > On Wed, Oct 16, 2013 at 04:13:37PM +0200, Fabio Fantoni wrote: > [...] >>>> - 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. >> > What do you mean by "in a single place"? They are two types of firmwares > doing the same thing. I mean ovmf with seabios inside it. This way we have a unique section xen side which would manage ovmf (with both uefi and bios support). This could be a support to every o.s. including ones that not support uefi. Take a look at these for example: http://www.seabios.org/pipermail/seabios/2013-January/005344.html http://www.seabios.org/pipermail/seabios/2013-February/005423.html Now it seems already on upstream git. Ian Campbell also seems to be in the thread about it and xen: http://www.seabios.org/pipermail/seabios/2013-February/005431.html > >>>> - 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. >> > My shallow understanding is that, they (QEMU, hvmloader or any other > firmwares) need to agree upon things. The point is they need to reach > consesus, no matter which one is in charge. Even if QEMU / OVMF takes > charge we would still face the same problem? > > On the other hand, it's critical for Xen to control those tables, > because obviously we trust the hypervisor more than external code. > > Wei. For the hvm domUs FWIK major part of devices are mainly managed by qemu. I found this link that probably helps to clarify one of the actual problem and I think it is a smart idea to reconsider actual hvmloader section (even if only in some parts): http://wiki.qemu.org/Features/ACPITableGeneration > Once implemented, QEMU will be able to extend information passed to > Guest OS through ACPI tables without need for bios code changes. This > is widely desired as a way to avoid the churn and proliferation of > QEMU-specific interfaces associated with ACPI tables in bios code. Anyway if my idea is stupid and unuseful sorry for wasting your time.