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

Re: [Xen-devel] [SeaBIOS] [PATCHv2 0/6] Improved multi-platform support



On Thu, 2013-02-14 at 14:23 +0000, David Woodhouse wrote:
> On Thu, 2013-02-14 at 14:08 +0000, Ian Campbell wrote:
> > The chap who did our OVMF stuff has moved on to pastures new but ISTR
> > him saying something about a build bug with GCC!=44, which had been
> > fixed in upstream OVMF but not yet sync'd into the Xen tree.
> 
> Yes, OVMF's toolchain handling is somewhat broken. I *do* have it
> building with GCC 4.6 and 4.7. There's a patch in my tree at git:// and
> http://git.infradead.org/users/dwmw2/edk2.git which fixes that...
> although I suspect it might be incomplete and I'm about to blow away my
> local build tree and configure from scratch to retest.
> 
> But your tools/ovmf-makefile could also do with s/GCC44/GCC4?/ in the
> line which does
>         cp Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ovmf.bin

Ack, thanks.

We try and support a reasonably wide range of hosts, usually we use
Debian Stable as our baseline (which is currently 4.4).

> 
> > Awesome! (I've CCd xen-devel just for their info, it's moderated for
> > non-subscribers but valid posters get whitelisted)
> 
> In that case I think the only context I need to add, for those who want
> to play along at home, is the location of my trees for OVMF and SeaBIOS.
> The OVMF one is above, and the SeaBIOS one is next to it:
> git:// or http://git.infradead.org/users/dwmw2/seabios.git
> 
> There's a README.CSM file in the SeaBIOS tree which describes how to
> build OVMF with CSM support.

Do I understand correctly from the README that once CSM support is
enabled at build time you can choose to use it dynamically at boot time?
If so, Neat!

I suppose this selection is persistent for a given VM, but where is it
saved?

>  The main reason I'm pointing you at my
> trees rather than upstream is the patch within each one that adds the
> UmbStart,UmbEnd fields for negotiating between UEFI and SeaBIOS which
> parts of the UMB memory region should be made read-only. For Qemu with
> KVM that's a moot point because it doesn't get made read-only anyway, so
> you could just use upstream now. If you don't implement the PAM
> protection of those regions, I suspect the same might be true for you.
> Suck it and see, perhaps.

Right, we really need to find someone with hours to finish properly
integrating OVMF.

> 
> > > I did need to fix the VGA ROM you're shipping for Cirrus, which has the
> > > PCIR structure unaligned. That was it.
> 
> > ... did you mean the VGA ROM we ship in the qemu-xen branch that we
> > include? (rather than tools/firmware/vgabios/)
> 
> Yes, the one in /usr/share/qemu-xen. You want the patch from
> http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg03650.html

Thanks.

-- 
Ian Campbell
Current Noise: W.A.S.P. - Harder, Faster

We don't need no education, we don't need no thought control.
                -- Pink Floyd


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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