On Tue, Nov 24, 2009 at 06:59:01PM +0200, Gleb Natapov wrote: > On Tue, Nov 24, 2009 at 10:57:02AM -0500, Kevin O'Connor wrote: > > On Mon, Nov 23, 2009 at 08:30:41PM +0200, Gleb Natapov wrote: > > > On Mon, Nov 23, 2009 at 07:15:55PM +0100, Sebastian Herbszt wrote: > > > > Ok - sounds good if bios_characteristics gets proper system based > > > > values. > > > > > > > Kevin can you help here. I can send a patch, but I am not sure I know > > > everything SeaBIOS supports. > > > > I don't know what bios_characteristics should be set to. > > > http://www.phoenix.com/NR/rdonlyres/51EEA1E6-20C1-4FA2-A3D8-AD8E45335C47/0/specssmbios.pdf > Page 30 have the description.
Bit 4 ISA is supported Bit 7 PCI is supported Bit 9 Plug and Play is supported Bit 10 APM is supported Bit 12 BIOS shadowing is allowed Bit 15 Boot from CD is supported Bit 16 Selectable Boot is supported Bit 19 EDD (Enhanced Disk Drive) Specification is supported Bit 22 Int 13h - 5.25" / 360 KB Floppy Services are supported Bit 23 Int 13h - 5.25" /1.2MB Floppy Services are supported Bit 24 Int 13h - 3.5" / 720 KB Floppy Services are supported Bit 25 Int 13h - 3.5" / 2.88 MB Floppy Services are supported Bit 27 Int 9h, 8042 Keyboard services are supported Bit 28 Int 14h, Serial Services are supported Bit 29 Int 17h, Printer Services are supported Bit 30 Int 10h, CGA/Mono Video Services are supported Several of the above are dependent on CONFIG_xxx settings. However, I'm not really sure how the above overlaps with your SVVP patch.. > It is used already where appropriate. To fill processor_id field in type > 4 table. CPU manufacturer is different issue. CPU a guest is running on is > not manufactured by Intel or AMD, it is emulated by QEMU. Okay. > > > > >>>>>>>- p->max_speed = 0; /* unknown */ > > > > >>>>>>>- p->current_speed = 0; /* unknown */ > > > > >>>>>>>+ p->max_speed = 2000; > > > > >>>>>>>+ p->current_speed = 2000; > > > > SeaBIOS detects the current Mhz - see calibrate_tsc() in src/clock.c. > > > How accurate is it? What if I boot 100 guests on 16 cpu host > simultaneously? Not uncommon scenario. It's not very accurate under qemu due to Linux power saving code which will frequently change cpu speeds. (The length of the runqueue doesn't seem to skew it, but the power stuff does.) >Those field really have no > meaning in virtualization environment. I'd rather have predictable > values there from boot to boot. Who know what Windows may use them for. Fair enough. There is also a risk that Windows will do the wrong thing with the dummy values. However, I agree with your point about consistency. -Kevin
