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

[Ian Campbell]

On Tue, 2013-02-12 at 18:58 +0100, Dario Faggioli wrote:
> So, what toolstack you want to use, is indeed up to you.

Using SeaBIOS requires you to use xl and not xend/xm, so there isn't
really any choice here. Which in turn implies that virt-* is not
currently an option so the direct command line method I outlined is the
way to go.

Ian.
-- 
Ian Campbell


I have not yet begun to byte!


signature.asc
Description: This is a digitally signed message part
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [RFC PATCH] VGA BIOS init fails if first mode used is graphical

[David Woodhouse]

On Wed, 2013-02-13 at 10:44 +0100, Fred . wrote:
> Can SeaBIOS init to a high resolution video mode such as 1920x1200?

I'm not entirely sure what you're asking. Can SeaVGABIOS initialise a
high-resolution mode? Yes. It supports 1920x1200 and 2560x1600 modes.
All you have to do is call INT 10h with the appropriate mode-setting
request.

Or are you asking if it can do so *power-up*, setting a graphical mode
so that nothing displays as expected, because operating systems and
bootloaders expect the screen to be in *text* mode? To which the answer
would be that yes it *can* be patched to do so, but that would be bad.

Or are you asking if it can do so for the OVMF/CSM case? In which case
again it *could* but OVMF is about to set the mode for itself anyway so
it would be pointless.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [RFC PATCH] VGA BIOS init fails if first mode used is graphical

[Fred .]

Can SeaBIOS init to a high resolution video mode such as 1920x1200?


On Wed, Feb 13, 2013 at 3:24 AM, Kevin O'Connor  wrote:

> On Fri, Feb 08, 2013 at 03:19:19PM +, David Woodhouse wrote:
> > On Fri, 2013-02-08 at 15:06 +, David Woodhouse wrote:
> > > When booting with OVMF+CSM, the first video mode that we ask for is
> mode
> > > 0x143. This doesn't seem to work; the qemu display window doesn't
> change
> > > size, and remains blank.
> > >
> > > If the first thing we ask for is a *text* mode, then things work fine.
> > > This is arguably a bug, but I'm not about to go chasing it.
> >
> > I should know never to say things like that; if I'm offended by
> > something it's almost always a lie to say that I won't actually go and
> > hunt it down. This patch is more minimal and highlights the actual
> > problem. Not sure what *else* is missing...
>
> Thanks.  The patch looks fine to me.  However, "-vga std" has stopped
> working for me (both before and after your patch) and I still need to
> track that down.
>
> -Kevin
>
> ___
> SeaBIOS mailing list
> SeaBIOS@seabios.org
> http://www.seabios.org/mailman/listinfo/seabios
>
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

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

[David Woodhouse]

I'm running Fedora 18 with Xen 4.2.1 but using the Fedora 17 3.7.3
kernel because the F18 3.7.6 kernel doesn't find its root filesystem
when booted under Xen. The Fedora KISS violation of using LVM by default
bites again... but that shouldn't make any difference, right? Xen and
all the userspace tools are up to date. And the kernel is fairly much
the same anyway.

I've made no changes to anything so far; I'm just using the standard
tools. It gets as far as the 'Daemon running' message, then sits there
doing nothing for about 35 seconds before exiting back to the shell
prompt. During that 35 seconds, a seabios domain does show up in 'xl
list' and 'xl top' (taking 100% CPU time). I don't see *any* SeaBIOS
output. This isn't a SeaBIOS with debug info (I'll possibly try that
next) but I ought at least to have seen the 'No bootable device'
message?

[root@i7 ~]# cat seabios.cfg 
builder = "hvm"
name = "seabios"
device_model_version_override = "qemu-xen"
memory = 512
serial = 'pty'
[root@i7 ~]# xl create -c seabios.cfg
Parsing config from seabios.cfg
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:0010->0019e3a8
  TOTAL: ->1f80
  ENTRY ADDRESS: 0010
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0200
  2MB PAGES: 0x00fb
  1GB PAGES: 0x
Daemon running with PID 3071

What's the best way to debug this?

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCH 0/5][RFC] Simultaneous multi-platform support

[David Woodhouse]

On Tue, 2013-02-12 at 21:27 -0500, Kevin O'Connor wrote:
> 
> I'm fine with that change, but I'm not sure how to communicate that to
> the distro maintainers.  I wouldn't want them to try and build the
> next version of xen and find it mysterously failing.

I'm not so worried about that. Xen ships its own seabios-config file and
is set up to build SeaBIOS for itself as part of its build process. So
distros who patch it to use their own prebuilt SeaBIOS (like Fedora
does) should expect to be at least watching for changes to the config
file.

However, if the Xen SeaBIOS image also wants some parts of CONFIG_QEMU
like the fw_cfg support, then I do start to wonder if it's actually
worth making that change anyway. It was a nice cleanup, with a bunch of 
s/if (CONFIG_QEMU && !runningOnXen())/if (CONFIG_QEMU)/ and
s/if (!CONFIG_QEMU || runningOnXen())/if (!CONFIG_QEMU)/

But now we'd have to add *back* some more complex conditions in other
places but I suppose it would still be a net win. I'll put it
together and test it, and we can make a decision. I really do need to
get my act together for testing under Xen *anyway* since I should test
OVMF+CSM there, so the effort involved in doing so is mostly not wasted.

> BTW, I did pull a bunch of other patches from your tree into the
> seabios repo.

Ta. I don't have a lot left, do I? :)

I've pushed my dregs out

- e1272ff8 Enable VGA output when settings bochs-specific mode

You're already looking at this one.

- 20bcdbcf Make Xen one of the top-level build target choices

Will test this and post a version for review.

- 4940c334 Clean up Kconfig options for CSM

Merging this would be good.

- d87fd3cc Add UmbStart,UmbEnd fields to EFI_COMPATIBILITY16_TABLE

Still chasing up the spec change...

- 4def181d Reject non-compliant PCI option ROMs with unaligned PCIR structure

We can drop this if you're not keen, but it *is* an option so people
could still keep compatibility with broken ROMs, and consistency is
good. We'd never have been shipping broken ROMs if we'd done this in the
first place...

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

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

[David Woodhouse]

On Tue, 2013-02-12 at 10:34 +, Ian Campbell wrote:
> 
> 
> Lastly to change the seabios bits, just change to
> tools/firmware/seabios-dir (assuming Fedora's packaging hasn't moved
> it)
> and git fetch/git reset/vim/emacs, the build system won't clobber this
> unless you ask it to. Then to rebuild:
> rm  tools/firmware/hvmloader/seabios.o \ 
> tools/firmware/seabios-dir/out/bios.bin \
> tools/firmware/hvmloader/roms.inc
> make -C tools/firmware

The standard way to rebuild Fedora packages is 'fedpkg clone' (which is
just a helper around 'git clone', then 'fedpkg local' to build them.

Fedora applies a patch to use a prebuilt bios.bin from their SeaBIOS
package instead of a build from within the Xen build tree; I've hacked
that further to set SEABIOS_ROM=/home/dwmw2/git/seabios/out/bios.bin
instead. Then 'make' in the tools/firmware/hvmloader directory, check
with 'strings' that my own build is actually in there, and add the
firmware_override line to the config as you suggested.

There is no change in behaviour; I still get 35 seconds of 'Daemon
running with PID ' and then it exits. I've enabled both debug-port
*and* serial debug (at 0x3f8) in my SeaBIOS build.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

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

[Ian Campbell]

On Wed, 2013-02-13 at 11:05 +, David Woodhouse wrote:
> I'm running Fedora 18 with Xen 4.2.1 but using the Fedora 17 3.7.3
> kernel because the F18 3.7.6 kernel doesn't find its root filesystem
> when booted under Xen. The Fedora KISS violation of using LVM by default
> bites again... but that shouldn't make any difference, right? Xen and
> all the userspace tools are up to date. And the kernel is fairly much
> the same anyway.

Right, the kernel shouldn't matter that much.

> I've made no changes to anything so far; I'm just using the standard
> tools. It gets as far as the 'Daemon running' message, then sits there
> doing nothing for about 35 seconds before exiting back to the shell
> prompt. During that 35 seconds, a seabios domain does show up in 'xl
> list' and 'xl top' (taking 100% CPU time). I don't see *any* SeaBIOS
> output. This isn't a SeaBIOS with debug info (I'll possibly try that
> next) but I ought at least to have seen the 'No bootable device'
> message?

You used -c so you should be connected to the virtual COM1, so if
SeaBIOS is logging anything to that you ought to see it. You could also
try enabling vnc in your config ("vnc = 1") and attaching to that. By
default it will find the first available port but you can force it with
vncdisplay=N (where N is 0,1,2 rather than 500N, IIRC).

You say it dies after 35 seconds, is the VM actually dying or is the
tool just giving up on the serial console? Sounds like the former from
your description.You might find adding:
on_shutdown = "preserve"
on_reboot = "preserve"
on_crash = "preserve"
to your config useful to give you enough time to connect to VNC and have
a proper look. You'll need to explicitly "xl destroy seabios" if you do
this.

Hopefully that will be enough to figure out what is going on, if not
then read on...

Is there anything of interest in /var/log/xen/*seabios* or "xl dmesg"?
Could you post the output of "xl -vvv create -c seabios.cfg" please.

Dario, have you ever run a domain with qemu-xen on a Fedora 18 box, it
ought to work, right?

> [root@i7 ~]# cat seabios.cfg 
> builder = "hvm"
> name = "seabios"
> device_model_version_override = "qemu-xen"
> memory = 512
> serial = 'pty'
> [root@i7 ~]# xl create -c seabios.cfg
> Parsing config from seabios.cfg
> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>   Loader:0010->0019e3a8
>   TOTAL: ->1f80
>   ENTRY ADDRESS: 0010
> xc: info: PHYSICAL MEMORY ALLOCATION:
>   4KB PAGES: 0x0200
>   2MB PAGES: 0x00fb
>   1GB PAGES: 0x
> Daemon running with PID 3071
> 
> What's the best way to debug this?

If the VNC console shows nothing then I find the easiest way is usually
to build a debug hypervisor so that the magic debug I/O port goes
somewhere useful.

Ian.

-- 
Ian Campbell

Laura's Law:
No child throws up in the bathroom.


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

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

[David Woodhouse]

On Wed, 2013-02-13 at 11:30 +, Ian Campbell wrote:
> 
> Is there anything of interest in /var/log/xen/*seabios* or "xl dmesg"?
> Could you post the output of "xl -vvv create -c seabios.cfg" please.
> 
> Dario, have you ever run a domain with qemu-xen on a Fedora 18 box, it
> ought to work, right?

Connecting with vnc actually works. It's running Bochs rombios and
powering off after 30 seconds. Was just trying to find the relevant goes
on how to make my seabios.cfg make it use SeaBIOS when your mail
arrived...

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCH 8/8] Convert some QEMU cmos config variables to the romfile interface.

[Paolo Bonzini]

Il 13/02/2013 02:57, Kevin O'Connor ha scritto:
>>> > > @@ -300,9 +300,8 @@ timer_setup(void)
>>> > >  SET_BDA(timer_counter, ticks);
>>> > >  
>>> > >  // Setup Century storage
>>> > > -if (CONFIG_QEMU) {
>>> > > -Century = inb_cmos(CMOS_CENTURY);
>>> > > -} else {
>>> > > +Century = romfile_loadint("etc/century", 0);
>>> > > +if (!Century) {
>>> > >  // Infer current century from the year.
>>> > >  u8 year = inb_cmos(CMOS_RTC_YEAR);
>>> > >  if (year > 0x80)
>> > 
>> > The right thing to would be to use the FADT century field.  In fact we
>> > should also set the century field to 0x32 under QEMU.
> I'm not much of a fan of storing content in the CMOS.

This is time data, where does it belong if not in the CMOS?

> It's fine on
> QEMU, but on real-hardware it tends to cause conflicts when switching
> between the factory bios and coreboot.  Since the century field isn't
> going to change for another 87 years I think it's safe to avoid cmos
> in this case.

I don't know what happens in real hardware if one uses INT 1Ah after
setting the RTC to binary mode, but the code above is wrong in this
case.  Also, there is an off-by-one error because 0x80 should be parsed
as 1980.  (For the same reason it's really 67 years not 87. :))

But yeah, nobody uses INT 1Ah probably, so it's not a big deal.

Paolo

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

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

[David Woodhouse]

On Wed, 2013-02-13 at 11:31 +, David Woodhouse wrote:
> On Wed, 2013-02-13 at 11:30 +, Ian Campbell wrote:
> > 
> > Is there anything of interest in /var/log/xen/*seabios* or "xl dmesg"?
> > Could you post the output of "xl -vvv create -c seabios.cfg" please.
> > 
> > Dario, have you ever run a domain with qemu-xen on a Fedora 18 box, it
> > ought to work, right?
> 
> Connecting with vnc actually works. It's running Bochs rombios and
> powering off after 30 seconds. Was just trying to find the relevant goes
> on how to make my seabios.cfg make it use SeaBIOS when your mail
> arrived...

s/goes/docs/ wtf. Anyway you'd already pointed me at xl.cfg(5). Which
says that seabios ought to have been the default if
device_model_version=qemu-xen. (Although you said to use
'device_model_version_override'...)

And when I set it explicitly it doesn't work...

[root@i7 ~]# cat seabios.cfg 
builder = "hvm"
name = "seabios"
device_model_version_override = "qemu-xen"
bios = 'seabios'
memory = 512
serial = 'pty'
firmware_override = 
'/home/dwmw2/fedora/xen/f18/xen-4.2.1/tools/firmware/hvmloader/hvmloader'

[root@i7 ~]# xl create -c -d  seabios.cfg
Parsing config from seabios.cfg
{"domid":null,"config":{"c_info":{"type":"hvm","hap":"","oos":"","ssidref":0,"name":"seabios","uuid":"a9784618-d101-437c-834e-f44181dcb236","xsdata":{},"platformdata":{},"poolid":0,"run_hotplug_scripts":"True"},"b_info":{"max_vcpus":0,"avail_vcpus":[],"cpumap":[],"numa_placement":"","tsc_mode":"default","max_memkb":524288,"target_memkb":524288,"video_memkb":-1,"shadow_memkb":4096,"rtc_timeoffset":0,"localtime":"","disable_migrate":"","cpuid":[],"blkdev_start":null,"device_model_version":null,"device_model_stubdomain":"","device_model":null,"device_model_ssidref":0,"extra":[],"extra_pv":[],"extra_hvm":[],"sched_params":{"sched":"unknown","weight":-1,"cap":-1,"period":-1,"slice":-1,"latency":-1,"extratime":-1},"ioports":[],"irqs":[],"u":{"firmware":"/home/dwmw2/fedora/xen/f18/xen-4.2.1/tools/firmware/hvmloader/hvmloader","bios":"seabios","pae":"","apic":"","acpi":"","acpi_s3":"","acpi_s4":"","nx":"","viridian":"","timeoffset":null,"hpet":"","vpt_align":"","timer_mode":null,"nested_hvm":"","nographic":"","vga":{"kind":null},"vnc":{"enable":"","listen":null,"passwd":null,"display":0,"findunused":""},"keymap":null,"sdl":{"enable":"","opengl":"","display":null,"xauthority":null},"spice":{"enable":"","port":0,"tls_port":0,"host":null,"disable_ticketing":"","passwd":null,"agent_mouse":""},"gfx_passthru":"","serial":"pty","boot":null,"usb":"","usbdevice":null,"soundhw":null,"xen_platform_pci":""}},"disks":[],"nics":[],"pcidevs":[],"vfbs":[],"vkbs":[],"on_poweroff":"destroy","on_reboot":"restart","on_watchdog":"destroy","on_crash":"destroy"}}
failed to free memory for the domain

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

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

[Ian Campbell]

On Wed, 2013-02-13 at 11:37 +, David Woodhouse wrote:
> device_model_version_override = "qemu-xen"

No "_override" on this option, sorry, that was my fault.

Ian.

-- 
Ian Campbell
Current Noise: Emperor - The Acclamation Of Bonds

poverty, n.:
An unfortunate state that persists as long
as anyone lacks anything he would like to have.


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

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

[David Woodhouse]

On Wed, 2013-02-13 at 11:40 +, Ian Campbell wrote:
> On Wed, 2013-02-13 at 11:37 +, David Woodhouse wrote:
> > device_model_version_override = "qemu-xen"
> 
> No "_override" on this option, sorry, that was my fault.

[root@i7 ~]# ls /usr/lib/xen/bin/
qemu-dm  stubdom-dm  stubdompath.sh  xenpaging

[root@i7 ~]# cat seabios.cfg 
builder = "hvm"
name = "seabios"
device_model_version = "qemu-xen"
memory = 512
serial = 'pty'
firmware_override = 
'/home/dwmw2/fedora/xen/f18/xen-4.2.1/tools/firmware/hvmloader/hvmloader'

[root@i7 ~]# xl create -c -d  seabios.cfg
Parsing config from seabios.cfg
{"domid":null,"config":{"c_info":{"type":"hvm","hap":"","oos":"","ssidref":0,"name":"seabios","uuid":"a2ced1af-b3ae-4efa-85d4-17f372acc5e2","xsdata":{},"platformdata":{},"poolid":0,"run_hotplug_scripts":"True"},"b_info":{"max_vcpus":0,"avail_vcpus":[],"cpumap":[],"numa_placement":"","tsc_mode":"default","max_memkb":524288,"target_memkb":524288,"video_memkb":-1,"shadow_memkb":4096,"rtc_timeoffset":0,"localtime":"","disable_migrate":"","cpuid":[],"blkdev_start":null,"device_model_version":"qemu_xen","device_model_stubdomain":"","device_model":null,"device_model_ssidref":0,"extra":[],"extra_pv":[],"extra_hvm":[],"sched_params":{"sched":"unknown","weight":-1,"cap":-1,"period":-1,"slice":-1,"latency":-1,"extratime":-1},"ioports":[],"irqs":[],"u":{"firmware":"/home/dwmw2/fedora/xen/f18/xen-4.2.1/tools/firmware/hvmloader/hvmloader","bios":null,"pae":"","apic":"","acpi":"","acpi_s3":"","acpi_s4":"","nx":"","viridian":"","timeoffset":null,"hpet":"","vpt_align":"","timer_mode":null,"nested_hvm":"","nographic":"","vga":{"kind":null},"vnc":{"enable":"","listen":null,"passwd":null,"display":0,"findunused":""},"keymap":null,"sdl":{"enable":"","opengl":"","display":null,"xauthority":null},"spice":{"enable":"","port":0,"tls_port":0,"host":null,"disable_ticketing":"","passwd":null,"agent_mouse":""},"gfx_passthru":"","serial":"pty","boot":null,"usb":"","usbdevice":null,"soundhw":null,"xen_platform_pci":""}},"disks":[],"nics":[],"pcidevs":[],"vfbs":[],"vkbs":[],"on_poweroff":"destroy","on_reboot":"restart","on_watchdog":"destroy","on_crash":"destroy"}}
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:0010->001be3a8
  TOTAL: ->1f80
  ENTRY ADDRESS: 0010
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0200
  2MB PAGES: 0x00fb
  1GB PAGES: 0x
libxl: error: libxl_dm.c:1086:libxl__spawn_local_dm: device model 
/usr/lib/xen/bin/qemu-system-i386 is not executable: No such file or directory
libxl: error: libxl_dm.c:1212:device_model_spawn_outcome: (null): spawn failed 
(rc=-3)
libxl: error: libxl_qmp.c:641:libxl__qmp_initialize: Connection error: No such 
file or directory
Daemon running with PID 5771
xenconsole: Could not read tty from store: No such file or directory
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console child [0] 
exited with error status 2


-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] Fedora 18 kernel and Xen [Was: Re: [PATCHv2 0/6] Improved multi-platform support]

[Dario Faggioli]

On Wed, 2013-02-13 at 11:05 +, David Woodhouse wrote:
> I'm running Fedora 18 with Xen 4.2.1 but using the Fedora 17 3.7.3
> kernel because the F18 3.7.6 kernel doesn't find its root filesystem
> when booted under Xen. 
>
Sorry for changing topic for a bit, but since I've been in this
situation you describe before, is it possible that you're hitting these:

 https://bugzilla.redhat.com/show_bug.cgi?id=783851
 http://markmail.org/message/k6gdno6mf7geynnl

If yes, just running `grub2-mkconfig -o /boot/grub2/grub.cfg' should fix
this, and you'll be able to use the new kernel.

Unfortunately, for now, that has to be done all the time Fedora updates
the kernel, because their use of grubby right after that (instead of
grub2-mkconfig), does not play well with Xen. We're working on trying to
fix this.

If that is not the case, sorry for interrupting the discussion. If it
is, I wish I could have been of help. :-)

Regards,
Dario

-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

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

[Ian Campbell]

On Wed, 2013-02-13 at 11:48 +, David Woodhouse wrote:
> On Wed, 2013-02-13 at 11:40 +, Ian Campbell wrote:
> > On Wed, 2013-02-13 at 11:37 +, David Woodhouse wrote:
> > > device_model_version_override = "qemu-xen"
> > 
> > No "_override" on this option, sorry, that was my fault.
> 
> [root@i7 ~]# ls /usr/lib/xen/bin/
> qemu-dm  stubdom-dm  stubdompath.sh  xenpaging

The qemu-dm here is the qemu-xen-traditional, i.e. the legacy Xen fork
of qemu which uses ROMBIOS not SeaBIOS.

> [root@i7 ~]# cat seabios.cfg 
> builder = "hvm"
> name = "seabios"
> device_model_version = "qemu-xen"
> memory = 512
> serial = 'pty'
> firmware_override = 
> '/home/dwmw2/fedora/xen/f18/xen-4.2.1/tools/firmware/hvmloader/hvmloader'
> 
> [root@i7 ~]# xl create -c -d  seabios.cfg
> Parsing config from seabios.cfg
> {"domid":null,"config":{"c_info":{"type":"hvm","hap":"","oos":"","ssidref":0,"name":"seabios","uuid":"a2ced1af-b3ae-4efa-85d4-17f372acc5e2","xsdata":{},"platformdata":{},"poolid":0,"run_hotplug_scripts":"True"},"b_info":{"max_vcpus":0,"avail_vcpus":[],"cpumap":[],"numa_placement":"","tsc_mode":"default","max_memkb":524288,"target_memkb":524288,"video_memkb":-1,"shadow_memkb":4096,"rtc_timeoffset":0,"localtime":"","disable_migrate":"","cpuid":[],"blkdev_start":null,"device_model_version":"qemu_xen","device_model_stubdomain":"","device_model":null,"device_model_ssidref":0,"extra":[],"extra_pv":[],"extra_hvm":[],"sched_params":{"sched":"unknown","weight":-1,"cap":-1,"period":-1,"slice":-1,"latency":-1,"extratime":-1},"ioports":[],"irqs":[],"u":{"firmware":"/home/dwmw2/fedora/xen/f18/xen-4.2.1/tools/firmware/hvmloader/hvmloader","bios":null,"pae":"","apic":"","acpi":"","acpi_s3":"","acpi_s4":"","nx":"","viridian":"","timeoffset":null,"hpet":"","vpt_align":"","timer_mode":null,"nested_hvm":"","nographic":"","vga":{"kind":null},"vnc":{"enable":"","listen":null,"passwd":null,"display":0,"findunused":""},"keymap":null,"sdl":{"enable":"","opengl":"","display":null,"xauthority":null},"spice":{"enable":"","port":0,"tls_port":0,"host":null,"disable_ticketing":"","passwd":null,"agent_mouse":""},"gfx_passthru":"","serial":"pty","boot":null,"usb":"","usbdevice":null,"soundhw":null,"xen_platform_pci":""}},"disks":[],"nics":[],"pcidevs":[],"vfbs":[],"vkbs":[],"on_poweroff":"destroy","on_reboot":"restart","on_watchdog":"destroy","on_crash":"destroy"}}
> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>   Loader:0010->001be3a8
>   TOTAL: ->1f80
>   ENTRY ADDRESS: 0010
> xc: info: PHYSICAL MEMORY ALLOCATION:
>   4KB PAGES: 0x0200
>   2MB PAGES: 0x00fb
>   1GB PAGES: 0x
> libxl: error: libxl_dm.c:1086:libxl__spawn_local_dm: device model 
> /usr/lib/xen/bin/qemu-system-i386 is not executable: No such file or directory

Hrm, this should either be provided by the Xen package (or maybe there
is a separate xen-qemu package?) or the Xen package should have been
patched to use the system qemu from /usr/bin. This is probably a
casualty of the upstream qemu-xen stuff being non-default in 4.2.x.

Does your /usr/bin/qemu-system-{i386,x86_64} link against any Xen
libraries? In which case you could try
device_model_override="/path/to/it"

Ian.

-- 
Ian Campbell
Current Noise: Emperor - With Strength I Burn

A good supervisor can step on your toes without messing up your shine.


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [BROKEN RFC 0/5] can we enable the qemu debug port for real-mode code?

[Laszlo Ersek]

On 02/13/13 06:19, Kevin O'Connor wrote:
> On Wed, Feb 13, 2013 at 04:52:09AM +0100, Laszlo Ersek wrote:
>> This series bears witness to my extreme cluelessness. With it I'm only
>> asking if we can move the hypervisor/platform detection logic to SRCBOTH
>> code, so that it sets up "PlatformRunningOn" for all of CSM, vgabios,
>> and "normal" SeaBIOS.
> 
> It's possible to do this, but it's not a great way of detecting the
> platform - it can only detect Xen/KVM and not raw QEMU.  On coreboot,
> it's possible to determine if qemu (or its derivatives) launched
> SeaBIOS by looking for the qemu signature in the vendor/part
> identifiers in the coreboot tables.  David suggested that something
> similar could be done for CSM by looking at the SMBIOS tables.
> 
>> The motivation is that running on qemu is now a
>> requirement for logging to the qemu debug port, and logging to that port
>> would be nice in all flavors & parts.
> 
> I recently pushed the "Improved multi-platform support" series, but I
> pulled out the CONFIG_DEBUG_IO change that allowed it to work with
> just CONFIG_QEMU_HARDWARE.

I think I understand. DEBUG_IO still depends on QEMU (from Gerd's commit
9600c800), and selecting CSM will not satisfy that.

> I think it's possible to get it working
> with CONFIG_QEMU_HARDWARE with something like the patch below.

Are two builds necessary with this change? One with CSM && QEMU_HARDWARE
(which will build a CSM-ized bios.bin that logs to the debug port, and a
vgabios.bin that doesn't), and another with QEMU (implying
QEMU_HARDWARE, from which build the bios.bin is to be ignored for CSM
purposes, and the vgabios.bin is to be installed, because it logs to the
debug port)?

> Also, the current SeaVGABIOS code is checking for "!COREBOOT" in its
> Kconfig file - that should be changed to "QEMU".  With that fixed this
> will be even less of a concern.  (It really only makes sense to build
> a cirrus/bochs vgabios for QEMU - which would always have the debug
> port available.)

Yes, I think it would eliminate the non-debugport-logging vgabios.bin
from the first (== CSM && QEMU_HARDWARE) build above.

... However, I think the (CSM && QEMU_HARDWARE) bios.bin would still not
log to the debug port. The (GET_GLOBAL(PlatformRunningOn) & PF_QEMU)
part would evaluate to false, for two reasons: first,
qemu_ramsize_preinit() will not set the flag when !CONFIG_QEMU (which is
implied by CONFIG_CSM); second, qemu_ramsize_preinit() is never even
invoked in the CSM build.

Anyway I've been beating this dead horse long enough; I guess I can
easily hack the DEBUG_IO dependency (and nothing else) in scratch builds.

Thanks for your help!
Laszlo


> 
> -Kevin
> 
> 
> diff --git a/Makefile b/Makefile
> index e02803e..b9fed0f 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -36,14 +36,14 @@ COMMONCFLAGS += $(call cc-option,$(CC),-nopie,)
>  COMMONCFLAGS += $(call cc-option,$(CC),-fno-stack-protector,)
>  COMMONCFLAGS += $(call cc-option,$(CC),-fno-stack-protector-all,)
>  
> -CFLAGS32FLAT := $(COMMONCFLAGS) -DMODE16=0 -DMODESEGMENT=0 
> -fomit-frame-pointer
> +CFLAGS32FLAT := $(COMMONCFLAGS) -DMODE16=0 -DMODESEGMENT=0 
> -fomit-frame-pointer -DMODEVGA=0
>  CFLAGSSEG := $(COMMONCFLAGS) -DMODESEGMENT=1 -fno-defer-pop \
>  $(call cc-option,$(CC),-fno-jump-tables,-DMANUAL_NO_JUMP_TABLE) \
>  $(call cc-option,$(CC),-fno-tree-switch-conversion,)
> -CFLAGS32SEG := $(CFLAGSSEG) -DMODE16=0 -fomit-frame-pointer
> +CFLAGS32SEG := $(CFLAGSSEG) -DMODE16=0 -fomit-frame-pointer -DMODEVGA=0
>  CFLAGS16INC := $(CFLAGSSEG) -DMODE16=1 -Wa,src/code16gcc.s \
>  $(call cc-option,$(CC),--param large-stack-frame=4,-fno-inline)
> -CFLAGS16 := $(CFLAGS16INC) -fomit-frame-pointer
> +CFLAGS16 := $(CFLAGS16INC) -fomit-frame-pointer -DMODEVGA=0
>  
>  # Run with "make V=1" to see the actual compile commands
>  ifdef V
> @@ -179,7 +179,7 @@ SRCVGA=src/output.c src/util.c src/pci.c \
>  vgasrc/stdvga.c vgasrc/stdvgamodes.c vgasrc/stdvgaio.c \
>  vgasrc/clext.c vgasrc/bochsvga.c vgasrc/geodevga.c
>  
> -CFLAGS16VGA = $(CFLAGS16INC) -Isrc
> +CFLAGS16VGA = $(CFLAGS16INC) -Isrc -DMODEVGA=1
>  
>  $(OUT)vgaccode16.raw.s: $(OUT)autoconf.h ; $(call whole-compile, 
> $(CFLAGS16VGA) -S, $(SRCVGA),$@)
>  
> diff --git a/src/Kconfig b/src/Kconfig
> index 4ddf9da..7df6c67 100644
> --- a/src/Kconfig
> +++ b/src/Kconfig
> @@ -406,7 +406,7 @@ menu "Debugging"
>  Base port for serial - generally 0x3f8, 0x2f8, 0x3e8, or 0x2e8.
>  
>  config DEBUG_IO
> -depends on QEMU && DEBUG_LEVEL != 0
> +depends on QEMU_HARDWARE && DEBUG_LEVEL != 0
>  bool "Special IO port debugging"
>  default y
>  help
> diff --git a/src/output.c b/src/output.c
> index e623d37..27621f5 100644
> --- a/src/output.c
> +++ b/src/output.c
> @@ -11,6 +11,7 @@
>  #include "bregs.h" // struct bregs
>  #include "config.h" // CONFIG_*
>  #include "biosvar.h" // GET_GLOBAL
> +#include "paravirt.h" // runningOnQEMU
>  
>  struct putcinfo {
> 

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

[David Woodhouse]

On Wed, 2013-02-13 at 12:05 +, Ian Campbell wrote:
> 
> Hrm, this should either be provided by the Xen package (or maybe there
> is a separate xen-qemu package?) or the Xen package should have been
> patched to use the system qemu from /usr/bin. This is probably a
> casualty of the upstream qemu-xen stuff being non-default in 4.2.x.
> 
> Does your /usr/bin/qemu-system-{i386,x86_64} link against any Xen
> libraries? In which case you could try
> device_model_override="/path/to/it"

Aha, the Fedora package has a 'qemu-xen.tradonly.patch' which comments
out the addition of qemu-xen-dir to SUBDIRS-$(CONFIG_IOEMU) in
tools/Makefile. Will there have been a *reason* they did that, or if I
build one and put it in the right place should it JustWork™? The patch
arrived in the package in a large commit with the comment 'Update to
xen-4.2.0' and no further explanation.

So much for it being easier to use the distro's toolsets with minimal
modification... :)

I have to run now, but will be back and prod at this a little more
later.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

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

[Ian Campbell]

On Wed, 2013-02-13 at 12:14 +, David Woodhouse wrote:
> On Wed, 2013-02-13 at 12:05 +, Ian Campbell wrote:
> > 
> > Hrm, this should either be provided by the Xen package (or maybe there
> > is a separate xen-qemu package?) or the Xen package should have been
> > patched to use the system qemu from /usr/bin. This is probably a
> > casualty of the upstream qemu-xen stuff being non-default in 4.2.x.
> > 
> > Does your /usr/bin/qemu-system-{i386,x86_64} link against any Xen
> > libraries? In which case you could try
> > device_model_override="/path/to/it"
> 
> Aha, the Fedora package has a 'qemu-xen.tradonly.patch' which comments
> out the addition of qemu-xen-dir to SUBDIRS-$(CONFIG_IOEMU) in
> tools/Makefile. Will there have been a *reason* they did that, or if I
> build one and put it in the right place should it JustWork™? The patch
> arrived in the package in a large commit with the comment 'Update to
> xen-4.2.0' and no further explanation.

I think it should JustWork. I expect they disabled it either because
they intended to eventually use /usr/bin/qemu-foo instead or maybe just
as an expedient way of getting the 4.2 package together and because it
is a non-default option in 4.2 (and something of a "preview" feature at
that).

> So much for it being easier to use the distro's toolsets with minimal
> modification... :)

Yers :-/

> I have to run now, but will be back and prod at this a little more
> later.

OK, thanks,

Ian.

-- 
Ian Campbell
Current Noise: Gojira - Explosia

Say "twenty-three-skiddoo" to logout.


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [RFC PATCH] VGA BIOS init fails if first mode used is graphical

[Fred .]

I was wondering if it could power-up in high resolution mode.
Didn't know nothing would work as expected.
I thought maybe bootloaders could use the same mode without reset the
display and set a new mode, and then the operating system does the same.
So the computer boots up and passes it to the bootloader which passes it to
the operating system all without ever changing screen mode or flicking
anything.

Doesn't Apple's computers do that? I don't know.

Would it be possible to boot in  a resolution any more modern than the old
IBM PC BIOS of 1980?
Which probably used same resolution as something from 1960 or 1970.

Maybe 132*60 instead of 40*25 or 80*25 rows/columns of text?


On Wed, Feb 13, 2013 at 11:10 AM, David Woodhouse wrote:

> On Wed, 2013-02-13 at 10:44 +0100, Fred . wrote:
> > Can SeaBIOS init to a high resolution video mode such as 1920x1200?
>
> I'm not entirely sure what you're asking. Can SeaVGABIOS initialise a
> high-resolution mode? Yes. It supports 1920x1200 and 2560x1600 modes.
> All you have to do is call INT 10h with the appropriate mode-setting
> request.
>
> Or are you asking if it can do so *power-up*, setting a graphical mode
> so that nothing displays as expected, because operating systems and
> bootloaders expect the screen to be in *text* mode? To which the answer
> would be that yes it *can* be patched to do so, but that would be bad.
>
> Or are you asking if it can do so for the OVMF/CSM case? In which case
> again it *could* but OVMF is about to set the mode for itself anyway so
> it would be pointless.
>
> --
> dwmw2
>
>
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

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

[M A Young]

On Wed, 13 Feb 2013, David Woodhouse wrote:


On Wed, 2013-02-13 at 12:05 +, Ian Campbell wrote:


Hrm, this should either be provided by the Xen package (or maybe there
is a separate xen-qemu package?) or the Xen package should have been
patched to use the system qemu from /usr/bin. This is probably a
casualty of the upstream qemu-xen stuff being non-default in 4.2.x.

Does your /usr/bin/qemu-system-{i386,x86_64} link against any Xen
libraries? In which case you could try
device_model_override="/path/to/it"


Aha, the Fedora package has a 'qemu-xen.tradonly.patch' which comments
out the addition of qemu-xen-dir to SUBDIRS-$(CONFIG_IOEMU) in
tools/Makefile. Will there have been a *reason* they did that, or if I
build one and put it in the right place should it JustWork™? The patch
arrived in the package in a large commit with the comment 'Update to
xen-4.2.0' and no further explanation.


xen-4.2.0 added a second qemu-xen image - the patch takes it out again. As 
the traditional qemu-xen was still the default so it didn't seem worth 
adding another, particularly as I would ideally like to drop xen's qemu 
altogether and go back to Fedora's.


As this seems to be about seabios, you should note that Fedora xen 4.2 
doesn't build its own seabios either, it uses the Fedora version - see the 
xen.use.fedora.seabios.patch patch. I didn't see any reason to duplicate 
what was already in Fedora (and as far as I understand it it is in general 
against Fedora's policy to do so).


Michael Young___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [RFC PATCH] VGA BIOS init fails if first mode used is graphical

[Gerd Hoffmann]

  Hi,

> So the computer boots up and passes it to the bootloader 

And here does the plan fail.  There is simply no way to do that.
Bootloaders expect the vga being in 80x25 text mode, period.

> Doesn't Apple's computers do that? I don't know.

Yes, they do.

> Would it be possible to boot in  a resolution any more modern than the old
> IBM PC BIOS of 1980?

As long as we are using the IBM PC BIOS interfaces if 1980 (which
seabios is all about):  No way.

With EFI (which apple uses btw) it's another story ...

cheers,
  Gerd


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

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

[David Woodhouse]

On Wed, 2013-02-13 at 12:38 +, M A Young wrote:
> 
> xen-4.2.0 added a second qemu-xen image - the patch takes it out again. As 
> the traditional qemu-xen was still the default so it didn't seem worth 
> adding another, particularly as I would ideally like to drop xen's qemu 
> altogether and go back to Fedora's.

Thanks for the quick response, Michael.

I'll enable the qemu-xen build again and then I should be fine. 

> As this seems to be about seabios, you should note that Fedora xen 4.2 
> doesn't build its own seabios either, it uses the Fedora version - see the 
> xen.use.fedora.seabios.patch patch. I didn't see any reason to duplicate 
> what was already in Fedora (and as far as I understand it it is in general 
> against Fedora's policy to do so).

Right. Although AFAICT nothing in your build of Xen will *use* this
SeaBIOS binary, since it's for the qemu-xen build that you disabled?

Anyway, when we get to the point that you're enabling qemu-xen in the
Fedora builds, I hope you'll be using just OVMF + SeaBIOS as a CSM, and
not having to mess around with a choice of firmwares according to what
you're booting in it today. I'll look at fixing that in the upstream Xen
build setup. But first I'll check I haven't broken native SeaBIOS... :)

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [BROKEN RFC 0/5] can we enable the qemu debug port for real-mode code?

[Kevin O'Connor]

On Wed, Feb 13, 2013 at 01:13:45PM +0100, Laszlo Ersek wrote:
> On 02/13/13 06:19, Kevin O'Connor wrote:
> > I think it's possible to get it working
> > with CONFIG_QEMU_HARDWARE with something like the patch below.
> 
> Are two builds necessary with this change? One with CSM && QEMU_HARDWARE
> (which will build a CSM-ized bios.bin that logs to the debug port, and a
> vgabios.bin that doesn't), and another with QEMU (implying
> QEMU_HARDWARE, from which build the bios.bin is to be ignored for CSM
> purposes, and the vgabios.bin is to be installed, because it logs to the
> debug port)?

If building for CSM, it's a separate build anyway - one for bios.bin
for QEMU and one for bios.bin for CSM (and another for bios.bin.elf
for coreboot if desired).  It only makes sense to build the vgabios
under QEMU as the virtual vga hardware is not really like any real
hardware (and the goal is for the CSM bios.bin to be to run on real
hardware).

> > Also, the current SeaVGABIOS code is checking for "!COREBOOT" in its
> > Kconfig file - that should be changed to "QEMU".  With that fixed this
> > will be even less of a concern.  (It really only makes sense to build
> > a cirrus/bochs vgabios for QEMU - which would always have the debug
> > port available.)
> 
> Yes, I think it would eliminate the non-debugport-logging vgabios.bin
> from the first (== CSM && QEMU_HARDWARE) build above.
> 
> ... However, I think the (CSM && QEMU_HARDWARE) bios.bin would still not
> log to the debug port. The (GET_GLOBAL(PlatformRunningOn) & PF_QEMU)
> part would evaluate to false, for two reasons: first,
> qemu_ramsize_preinit() will not set the flag when !CONFIG_QEMU (which is
> implied by CONFIG_CSM); second, qemu_ramsize_preinit() is never even
> invoked in the CSM build.

It would be incorrect to call qemu_ramsize_preinit in a CSM boot as
the ramsize needs to come from UEFI in that situation (and not
directly from QEMU).  I think the high-level plan in this case is to
detect that the code is running under QEMU by inspecting the SMBIOS
tables passed in from UEFI and then set the flag.

-Kevin

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

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

[David Woodhouse]

On Wed, 2013-02-13 at 12:56 +, Ian Campbell wrote:
> 
> I think it should JustWork. I expect they disabled it either because
> they intended to eventually use /usr/bin/qemu-foo instead or maybe just
> as an expedient way of getting the 4.2 package together and because it
> is a non-default option in 4.2 (and something of a "preview" feature at
> that).

OK... I re-enabled it, I now have a /usr/lib/xen/bin/qemu-system-i386
(not x86_64 but that's fine for now) which *does* appear to have Xen
support.

[root@i7 ~]# xl create -c -d  seabios.cfg
Parsing config from seabios.cfg
{"domid":null,"config":{"c_info":{"type":"hvm","hap":"","oos":"","ssidref":0,"name":"seabios","uuid":"849a47f8-1333-45e1-b4a6-cde90429cfd4","xsdata":{},"platformdata":{},"poolid":0,"run_hotplug_scripts":"True"},"b_info":{"max_vcpus":0,"avail_vcpus":[],"cpumap":[],"numa_placement":"","tsc_mode":"default","max_memkb":524288,"target_memkb":524288,"video_memkb":-1,"shadow_memkb":4096,"rtc_timeoffset":0,"localtime":"","disable_migrate":"","cpuid":[],"blkdev_start":null,"device_model_version":"qemu_xen","device_model_stubdomain":"","device_model":null,"device_model_ssidref":0,"extra":[],"extra_pv":[],"extra_hvm":[],"sched_params":{"sched":"unknown","weight":-1,"cap":-1,"period":-1,"slice":-1,"latency":-1,"extratime":-1},"ioports":[],"irqs":[],"u":{"firmware":"/home/dwmw2/fedora/xen/f18/xen-4.2.1/tools/firmware/hvmloader/hvmloader","bios":null,"pae":"","apic":"","acpi":"","acpi_s3":"","acpi_s4":"","nx":"","viridian":"","timeoffset":null,"hpet":"","vpt_align":"","timer_mode":null,"nested_hvm":"","nographic":"","vga":{"kind":null},"vnc":{"enable":"","listen":null,"passwd":null,"display":0,"findunused":""},"keymap":null,"sdl":{"enable":"","opengl":"","display":null,"xauthority":null},"spice":{"enable":"","port":0,"tls_port":0,"host":null,"disable_ticketing":"","passwd":null,"agent_mouse":""},"gfx_passthru":"","serial":"pty","boot":null,"usb":"","usbdevice":null,"soundhw":null,"xen_platform_pci":""}},"disks":[],"nics":[],"pcidevs":[],"vfbs":[],"vkbs":[],"on_poweroff":"destroy","on_reboot":"restart","on_watchdog":"destroy","on_crash":"destroy"}}
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:0010->001be3a8
  TOTAL: ->1f80
  ENTRY ADDRESS: 0010
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0200
  2MB PAGES: 0x00fb
  1GB PAGES: 0x
Daemon running with PID 1383
xenconsole: Could not read tty from store: No such file or directory
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console child [0] 
exited with error status 2

At this point, the 'xl create' command is running in the background,
appending this to xl-seabios.log every few seconds...

xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:0010->001be3a8
  TOTAL: ->1f80
  ENTRY ADDRESS: 0010
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0200
  2MB PAGES: 0x00fb
  1GB PAGES: 0x
Waiting for domain seabios (domid 253) to die [pid 1384]
Domain 253 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 253 needs to be cleaned up: destroying the domain
Done. Rebooting now

I can strace it and see that it *is* invoking qemu and then almost
immediately sending it a SIGHUP for reasons I don't quite understand.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [RFC PATCH] VGA BIOS init fails if first mode used is graphical

[David Woodhouse]

On Wed, 2013-02-13 at 12:50 +0100, Fred . wrote:
> Would it be possible to boot in  a resolution any more modern than the
> old IBM PC BIOS of 1980?
> Which probably used same resolution as something from 1960 or 1970.
> Maybe 132*60 instead of 40*25 or 80*25 rows/columns of text?

Please don't top-post. Do me the courtesy of properly trimming your
citations to quote *only* what is needed for context, and place your
reply *below* it, if you want me to do you the courtesy of taking the
time to reply. I will not reply to another top-posted message.

I really don't understand what you're even trying to achieve. The whole
*POINT* of SeaBIOS is to emulate the old IBM PC BIOS of 1980. Well, and
a few later developments, but basically that's the point.

DOS, and various other 16-bit bootloaders and operating systems, will
expect the standard 80x25 text mode. If they don't find that, then they
will fail to work correctly. Anything *else* can call the standard INT
10h video BIOS calls to set whatever mode it wants.

What user experience do you actually expect to achieve, from the changes
that you're suggesting?

Bootloaders like Grub these days will already use graphical modes. The
SeaBIOS splash screen can also be graphical, and you can go seamlessly
from one to the other. What is it that you actually *want*, in real
terms? I'm not even sure you know...

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [RFC PATCH] VGA BIOS init fails if first mode used is graphical

[Fred .]

On Wed, Feb 13, 2013 at 5:15 PM, David Woodhouse wrote:

> What user experience do you actually expect to achieve, from the changes
> that you're suggesting?
>
> Bootloaders like Grub these days will already use graphical modes. The
> SeaBIOS splash screen can also be graphical, and you can go seamlessly
> from one to the other. What is it that you actually *want*, in real
> terms? I'm not even sure you know...
>

Yeah, I was thinking along the lines of using a splash screen then GRUB use
the same resolution and the same splash screen and it would transition
smoothly without any flicker or resetting of the screen mode, and then it
would go from there to Plymouth which would use the same splash screen, and
it would transition smoothly to the login manager.

>From boot to desktop, always in 1900x1200. Smooth experience. No flicker.
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCH 8/8] Convert some QEMU cmos config variables to the romfile interface.

[Kevin O'Connor]

On Wed, Feb 13, 2013 at 12:33:20PM +0100, Paolo Bonzini wrote:
> Il 13/02/2013 02:57, Kevin O'Connor ha scritto:
> >> > The right thing to would be to use the FADT century field.  In fact we
> >> > should also set the century field to 0x32 under QEMU.
> > I'm not much of a fan of storing content in the CMOS.
> 
> This is time data, where does it belong if not in the CMOS?

It still has the challenge of knowing where in the CMOS to put it, and
where in the CMOS to update the checksum if it needs to change.

That aside, though, I'm not really happy about patch 8 anyway -
additional complexity and indirection for no real gain, so I'll
withdraw patch 8 for consideration.  The first 7 patches I think are
still a simplification.

Thanks.
-Kevin

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] [PATCH] vgabios: Bochs/QEMU vgabios support should depend on CONFIG_QEMU.

[Kevin O'Connor]

The Cirrus, Standard VGA, and Bochs VGA should depend on CONFIG_QEMU
and not CONFIG_COREBOOT.

Signed-off-by: Kevin O'Connor 
---
 vgasrc/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/vgasrc/Kconfig b/vgasrc/Kconfig
index 089a447..0901c04 100644
--- a/vgasrc/Kconfig
+++ b/vgasrc/Kconfig
@@ -11,14 +11,14 @@ menu "VGA ROM"
 Do not build a VGA BIOS.
 
 config VGA_STANDARD_VGA
-depends on !COREBOOT
+depends on QEMU
 bool "QEMU/Bochs Original IBM 256K VGA"
 help
 Build basic VGA BIOS support (pre Super-VGA) for use
 on emulators.
 
 config VGA_CIRRUS
-depends on !COREBOOT
+depends on QEMU
 bool "QEMU/Bochs Cirrus SVGA"
 help
 Build support for Cirrus VGA emulation found on QEMU
@@ -26,7 +26,7 @@ menu "VGA ROM"
 intended for use on real Cirrus hardware.
 
 config VGA_BOCHS
-depends on !COREBOOT
+depends on QEMU
 bool "QEMU/Bochs VBE SVGA"
 help
 Build support for Bochs DISPI interface (a custom VBE
-- 
1.7.11.7


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCH 0/5][RFC] Simultaneous multi-platform support

[Kevin O'Connor]

On Wed, Feb 13, 2013 at 09:50:13AM +, David Woodhouse wrote:
> However, if the Xen SeaBIOS image also wants some parts of CONFIG_QEMU
> like the fw_cfg support, then I do start to wonder if it's actually
> worth making that change anyway. It was a nice cleanup, with a bunch of 
> s/if (CONFIG_QEMU && !runningOnXen())/if (CONFIG_QEMU)/ and
> s/if (!CONFIG_QEMU || runningOnXen())/if (!CONFIG_QEMU)/

Another way to tackle this might be to just group all the qemu and xen
calls into paravirt.c.  That retains runningOnXen, but it's not spread
around as much.  See patch below as an idea.

-Kevin


diff --git a/src/coreboot.c b/src/coreboot.c
index c0c6653..0d44834 100644
--- a/src/coreboot.c
+++ b/src/coreboot.c
@@ -13,6 +13,8 @@
 #include "disk.h" // MAXDESCSIZE
 #include "config.h" // CONFIG_*
 #include "acpi.h" // find_pmtimer
+#include "pci.h" // pci_probe_devices
+
 
 /
  * Memory map
@@ -125,6 +127,9 @@ const char *CBvendor = "", *CBpart = "";
 void
 coreboot_preinit(void)
 {
+if (!CONFIG_COREBOOT)
+return;
+
 dprintf(3, "Attempting to find coreboot table\n");
 
 // Find coreboot table.
@@ -204,10 +209,14 @@ scan_tables(u32 start, u32 size)
 }
 
 void
-coreboot_biostable_setup(void)
+coreboot_platform_setup(void)
 {
+if (!CONFIG_COREBOOT)
+return;
+pci_probe_devices();
+
 struct cb_memory *cbm = CBMemTable;
-if (! CONFIG_COREBOOT || !cbm)
+if (!cbm)
 return;
 
 dprintf(3, "Relocating coreboot bios tables\n");
diff --git a/src/mtrr.c b/src/mtrr.c
index 0575b14..56f85f9 100644
--- a/src/mtrr.c
+++ b/src/mtrr.c
@@ -6,7 +6,6 @@
 
 #include "util.h" // dprintf
 #include "config.h" // CONFIG_*
-#include "paravirt.h" // runningOnXen
 #include "pci.h" // pcimem_start
 
 #define MSR_MTRRcap0x00fe
@@ -34,7 +33,7 @@
 
 void mtrr_setup(void)
 {
-if (!CONFIG_MTRR_INIT || runningOnXen())
+if (!CONFIG_MTRR_INIT)
 return;
 
 u32 eax, ebx, ecx, edx, cpuid_features;
diff --git a/src/paravirt.c b/src/paravirt.c
index aa4a421..f76b47f 100644
--- a/src/paravirt.c
+++ b/src/paravirt.c
@@ -19,6 +19,7 @@
 #include "acpi.h" // acpi_setup
 #include "mptable.h" // mptable_setup
 #include "pci.h" // create_pirtable
+#include "xen.h" // xen_biostable_setup
 
 /* This CPUID returns the signature 'KVMKVMKVM' in ebx, ecx, and edx.  It
  * should be used to determine that a VM is running under KVM.
@@ -45,11 +46,16 @@ static void kvm_preinit(void)
 }
 
 void
-qemu_ramsize_preinit(void)
+qemu_preinit(void)
 {
 if (!CONFIG_QEMU)
 return;
 
+if (runningOnXen()) {
+xen_ramsize_preinit();
+return;
+}
+
 PlatformRunningOn = PF_QEMU;
 kvm_preinit();
 
@@ -77,8 +83,27 @@ qemu_ramsize_preinit(void)
 }
 
 void
-qemu_biostable_setup(void)
+qemu_platform_setup(void)
 {
+if (!CONFIG_QEMU)
+return;
+
+if (runningOnXen()) {
+pci_probe_devices();
+xen_hypercall_setup();
+xen_biostable_setup();
+return;
+}
+
+// Initialize pci
+pci_setup();
+smm_setup();
+
+// Initialize mtrr and smp
+mtrr_setup();
+smp_setup();
+
+// Create bios tables
 pirtable_setup();
 mptable_setup();
 smbios_setup();
diff --git a/src/paravirt.h b/src/paravirt.h
index 4438273..96b35ba 100644
--- a/src/paravirt.h
+++ b/src/paravirt.h
@@ -23,8 +23,8 @@ static inline int runningOnKVM(void) {
 return CONFIG_QEMU && GET_GLOBAL(PlatformRunningOn) & PF_KVM;
 }
 
-void qemu_ramsize_preinit(void);
-void qemu_biostable_setup(void);
+void qemu_preinit(void);
+void qemu_platform_setup(void);
 void qemu_cfg_init(void);
 
 #endif
diff --git a/src/pciinit.c b/src/pciinit.c
index 1d34653..d757ab6 100644
--- a/src/pciinit.c
+++ b/src/pciinit.c
@@ -11,7 +11,6 @@
 #include "pci_regs.h" // PCI_COMMAND
 #include "ioport.h" // PORT_ATA1_CMD_BASE
 #include "config.h" // CONFIG_*
-#include "paravirt.h" // runningOnXen
 #include "memmap.h" // add_e820
 #include "dev-q35.h"
 
@@ -734,11 +733,8 @@ static void pci_bios_map_devices(struct pci_bus *busses)
 void
 pci_setup(void)
 {
-if (!CONFIG_QEMU || runningOnXen()) {
-// PCI setup already done by coreboot or Xen - just do probe.
-pci_probe_devices();
+if (!CONFIG_QEMU)
 return;
-}
 
 dprintf(3, "pci setup\n");
 
diff --git a/src/post.c b/src/post.c
index 3af3638..f2eded9 100644
--- a/src/post.c
+++ b/src/post.c
@@ -159,24 +159,9 @@ platform_hardware_setup(void)
 mathcp_setup();
 timer_setup();
 
-// Initialize pci
-pci_setup();
-smm_setup();
-
-// Initialize mtrr and smp
-mtrr_setup();
-smp_setup();
-
-// Setup Xen hypercalls
-xen_hypercall_setup();
-
-// Setup external BIOS interface tables
-if (CONFIG_COREBOOT)
-coreboot_biostable_setup();
-else if (runningOnXen())
-xen_biostable_setup();
-else
-qemu_biostable_setup();
+// Platform

Re: [SeaBIOS] [PATCH 0/5][RFC] Simultaneous multi-platform support

[Kevin O'Connor]

On Wed, Feb 13, 2013 at 09:50:13AM +, David Woodhouse wrote:
> - 4940c334 Clean up Kconfig options for CSM
> 
> Merging this would be good.

The "BIOS interfaces" menu allows developers to turn off bios features
for testing or to shrink the SeaBIOS binary size.  I don't see a gain
to limiting what devs can turn off.  Turning off CONFIG_BOOT could be
useful - an embedded device might want support for running legacy
option roms under UEFI but know it will never need to boot in legacy
mode.  CONFIG_OPTIONROMS doesn't do anything under CSM, but maybe it
makes sense to add "if (!CONFIG_OPTIONROMS) return" to the top of
handle_csm_0005.

Granted, CONFIG_OPTIONROMS_DEPLOYED isn't terribly useful - it's
probably about time all that code was just removed.  (Or at least set
to depends on QEMU.)

> - 4def181d Reject non-compliant PCI option ROMs with unaligned PCIR structure
> 
> We can drop this if you're not keen, but it *is* an option so people
> could still keep compatibility with broken ROMs, and consistency is
> good. We'd never have been shipping broken ROMs if we'd done this in the
> first place...

I don't see why one would want to enable an option that will cause the
boot to fail mysteriously for some users.  It wouldn't be a problem if
we thought all roms followed the spec, but we know the current "lgpl
vgabios" violates this.  How about the following instead:

--- a/src/optionroms.c
+++ b/src/optionroms.c
@@ -109,6 +109,9 @@ get_pci_rom(struct rom_header *rom)
 struct pci_data *pd = (void*)((u32)rom + rom->pcioffset);
 if (pd->signature != PCI_ROM_SIGNATURE)
 return NULL;
+if (rom->pcioffset & 3)
+dprintf(1, "WARNING! Found unaligned PCI rom (vd=%04x:%04x)\n"
+, pd->vendor, pd->device);
 return pd;
 }
 
-Kevin

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCH 0/5][RFC] Simultaneous multi-platform support

[David Woodhouse]

On Wed, 2013-02-13 at 20:02 -0500, Kevin O'Connor wrote:
> On Wed, Feb 13, 2013 at 09:50:13AM +, David Woodhouse wrote:
> > - 4940c334 Clean up Kconfig options for CSM
> > 
> > Merging this would be good.
> 
> The "BIOS interfaces" menu allows developers to turn off bios features
> for testing or to shrink the SeaBIOS binary size.  I don't see a gain
> to limiting what devs can turn off.  Turning off CONFIG_BOOT could be
> useful - an embedded device might want support for running legacy
> option roms under UEFI but know it will never need to boot in legacy
> mode.  CONFIG_OPTIONROMS doesn't do anything under CSM, but maybe it
> makes sense to add "if (!CONFIG_OPTIONROMS) return" to the top of
> handle_csm_0005.

I'm dubious about the sanity of those who use UEFI and yet also actually
care about the size of their firmware. But yes, that makes a certain
amount of sense. I'll look at implementing the CONFIG_BOOT part of it at
least, and I might as well do the CONFIG_OPTIONROMS bit as you suggest
too.

> Granted, CONFIG_OPTIONROMS_DEPLOYED isn't terribly useful - it's
> probably about time all that code was just removed.  (Or at least set
> to depends on QEMU.)

OK.

> +if (rom->pcioffset & 3)
> +dprintf(1, "WARNING! Found unaligned PCI rom (vd=%04x:%04x)\n"
> +, pd->vendor, pd->device);

Yeah, that works.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] [PATCH] Enable VGA output when setting Cirrus-specific mode

[Laszlo Ersek]

This patch does the same for Cirrus as David's following patch for bochs,
originally posted under
:

  Enable VGA output when settings bochs-specific mode

  When used from OVMF+CSM, we got no video output. It appears that we were
  never enabling the display output except when configuring a text mode.
  Which never happens, in the OVMF+CSM case.

In my testing on RHEL-6.3 with OVMF -D CSM_ENABLE / CONFIG_CSM bios.bin /
CONFIG_QEMU vgabios.bin, using Cirrus, VESA mode 0x115 is selected (Direct
Color, 800x600x24).

According to ,

  cirrus_switch_mode()
stdvga_attr_mask()

currently keeps/sets the "Attribute Controller Graphics Enable" bit set in
the "Attribute Mode Control Register". When invoked from OVMF+CSM, that is
not enough however, so let's do the same as for Bochs:

  stdvga_attrindex_write(0x20);

which corresponds to setting the "Palette Address Source" bit in the
"Attribute Address Register":

  "This bit is set to 0 to load color values to the registers in the
  internal palette. It is set to 1 for normal operation of the attribute
  controller. [...]"

clext_set_mode()
  stdvga_set_mode() -- for regular modes
stdvga_attrindex_write() -- existing call
  cirrus_switch_mode() -- for Cirrus modes
stdvga_attrindex_write() -- call added by this patch

Signed-off-by: Laszlo Ersek 
---
 My motivation for using Cirrus instead of stdvga is three-fold:
 - using libvirt on RHEL-6.3, Cirrus seems to be the default video card
   for the guests I tend to create,
 - it provides better max resolution in the Fedora 18 guest,
 - for some reason (maybe due to kernel build options?) the Fedora 18
   guest can't display character mode consoles on stdvga, but works well
   with Cirrus. (F18/Xorg/{stdvga,cirrus} are OK, and so are
   RHEL6/{Xorg,console}/{stdvga,cirrus}.)
 Tested with RHEL-6, Fedora 18, and Windows 8 Consumer Preview. 

 vgasrc/clext.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/vgasrc/clext.c b/vgasrc/clext.c
index dd45df3..d02b880 100644
--- a/vgasrc/clext.c
+++ b/vgasrc/clext.c
@@ -433,6 +433,7 @@ cirrus_switch_mode(struct cirrus_mode_s *table)
 else if (memmodel != MM_TEXT)
 on = 0x01;
 stdvga_attr_mask(0x10, 0x01, on);
+stdvga_attrindex_write(0x20);
 }
 
 static void
-- 
1.7.1


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] [PATCH] USB-EHCI: Fix null pointer assignment

[Avik Sil]

cntl->regs should not be accessed before initializing it.

Signed-off-by: Avik Sil 
---
 src/usb-ehci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/usb-ehci.c b/src/usb-ehci.c
index f28f343..69a9194 100644
--- a/src/usb-ehci.c
+++ b/src/usb-ehci.c
@@ -347,9 +347,9 @@ ehci_setup(struct pci_device *pci, int busid, struct 
pci_device *comppci)
 cntl->usb.pci = pci;
 cntl->usb.type = USB_TYPE_EHCI;
 cntl->caps = caps;
+cntl->regs = (void*)caps + readb(&caps->caplength);
 if (hcc_params & HCC_64BIT_ADDR)
 cntl->regs->ctrldssegment = 0;
-cntl->regs = (void*)caps + readb(&caps->caplength);
 
 dprintf(1, "EHCI init on dev %02x:%02x.%x (regs=%p)\n"
 , pci_bdf_to_bus(bdf), pci_bdf_to_dev(bdf)
-- 
1.7.11.7


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios