SeaBIOS

seabios@seabios.org

10 participants
3770 discussions

Re: [SeaBIOS] [Qemu-devel] Re: Unusual physical address when using 64-bit BAR
by Isaku Yamahata 30 Aug '10

30 Aug '10

Added Cc: seabios(a)seabios.org On Wed, Jul 21, 2010 at 06:31:01AM +0300, Michael S. Tsirkin wrote: > On Tue, Jul 20, 2010 at 06:52:23PM +0900, Isaku Yamahata wrote: > > On Wed, Jul 14, 2010 at 09:10:28AM -0600, Cam Macdonell wrote: > > > On Tue, Jul 13, 2010 at 8:52 PM, Isaku Yamahata <yamahata(a)valinux.co.jp> wrote: > > > > On Tue, Jul 13, 2010 at 04:48:19PM -0600, Cam Macdonell wrote: > > > >> On Tue, Jul 13, 2010 at 2:41 PM, Isaku Yamahata <yamahata(a)valinux.co.jp> wrote: > > > >> > On Tue, Jul 13, 2010 at 02:05:51PM -0600, Cam Macdonell wrote: > > > >> >> >> > Seabios completely ignore the 64-bitness of the BAR. ?Looks like it also > > > >> >> >> > thinks the second half of the BAR is an I/O region instead of memory (hence > > > >> >> >> > the c200, that's part of the pci portio region. > > > >> >> > > > > >> >> > I've sent the patches to address it. But they haven't been merged yet. > > > >> >> > seabios doesn't map BARs beyond 4GB. > > > >> >> > If bar is mapped beyond 4GB, guest BIOS does it. > > > >> >> > > > >> >> Have those patches been merged yet? > > > >> > > > > >> > They have been merged into seabios upstream now. > > > >> > qemu seabios fork hasn't pulled for a while, though. > > > >> > > > > >> > > > > >> >> > To see how seabios works, it would help to increase CONFIG_DEBUG_LEVEL > > > >> >> > in config.h of seabios > > > >> >> > > > >> >> Where does the output from seabios end up? ?Inside dmesg? > > > >> > > > > >> > It outputs them to the serial console which qemu emulates. > > > >> > seabios is out of kernel control, so dmesg doesn't show it. > > > >> > > > > >> > > > > >> >> >> pci_read_config: (val) 0x0 <- 0x1c (addr) > > > >> >> >> pci_write_config: (val) 0x0 -> 0x1c (addr) > > > >> >> >> pci_read_config: (val) 0xffffffff <- 0x1c (addr) > > > >> >> >> pci_write_config: (val) 0x0 -> 0x1c (addr) > > > >> >> >> pci_read_config: (val) 0x0 <- 0x1c (addr) > > > >> >> >> pci_write_config: (val) 0x0 -> 0x1c (addr) > > > >> >> > > > > >> >> > seabios BAR3. Not sure how it is mapped from this > > > >> >> > message. > > > >> >> > > > >> >> Isn't the BAR3 from the fact that a 64-bit BAR would use both BAR2 and > > > >> >> BAR3 to store all 64-bits? > > > >> > > > > >> > Yes. Seabios misbehaves. 64bit bar is(was) a missing feature. > > > >> > -- > > > >> > yamahata > > > >> > > > > >> > > > > >> > > > >> With the latest seabios git passed via -bios, I no longer see the > > > >> 48-bit address, but instead a 32-bit address and then > > > >> ffffffff00000000. ?This guest has 1gb of RAM so the address isn't be > > > >> mapped beyond 4g. > > > > > > > > Can I see the debug log like before? > > > > (hopefully seabios with CONFIG_DEBUG_LEVEL enabled.) > > > > > > Here's the dump from SeaBIOS in the region related to the PCI devices. > > > The SeaBIOS output is identical whether the BAR is 32-bit or 64-bit. > > > > > > PCI: bus=0 devfn=0x10: vendor_id=0x1013 device_id=0x00b8 > > > region 0: 0xf0000000 > > > region 1: 0xf2000000 > > > region 6: 0xf2010000 > > > PCI: bus=0 devfn=0x18: vendor_id=0x1af4 device_id=0x1000 > > > region 0: 0x0000c020 > > > region 1: 0xf2020000 > > > region 6: 0xf2030000 > > > PCI: bus=0 devfn=0x20: vendor_id=0x1af4 device_id=0x1110 > > > region 0: 0xf2040000 > > > region 1: 0xf2041000 > > > region 2: 0x00000000 > > > > Is this region (region 2 of devfn=0x20: vendor_id=0x1af4 device_id=0x1110) > > the BAR in quistion? > > The value 0 seems odd. Probably BAR address calculation overflowed. > > Currently seabios doesn't check overflow. I attached the patch. > > > > > > > > Do you know who sets the BAR to ffffffff00000000? > > > > > > Here are the config reads/writes related to the 0x18/1c, the 'IVSHMEM' > > > lines are from the map function passed to pci_register_bar(). It > > > looks like SeaBIOS sets the address to 0 and then the potentially > > > useful e0000000 address gets mangled into ffffffff000000. > > > > There is something wrong with the debug message of write case, I suppose. > > All written value are 0, but the resulted effect doesn't seems so. > > > > > > > > IVSHMEM: guest pci addr = 0, guest h/w addr = 1090912256, size = 536870912 > > > > > > ...snip... > > > > > > pci_read_config: (val) 0x4 <- 0x18 (addr) > > > pci_write_config: (val) 0x0 -> 0x18 (addr) > > > IVSHMEM: guest pci addr = e0000000, guest h/w addr = 1090912256, size = 20000000 > > > > If 0 is written to 0x18, the bar address should be 0, but it says e0000000. > > > > > pci_read_config: (val) 0xe0000004 <- 0x18 (addr) > > > > The read value isn't 0. and so on... > > > > > pci_write_config: (val) 0x0 -> 0x18 (addr) > > > pci_read_config: (val) 0x0 <- 0x1c (addr) > > > pci_write_config: (val) 0x0 -> 0x1c (addr) > > > IVSHMEM: guest pci addr = ffffffff00000000, guest h/w addr = > > > 1090912256, size = 20000000 > > > pci_read_config: (val) 0xffffffff <- 0x1c (addr) > > > pci_write_config: (val) 0x0 -> 0x1c (addr) > > > > > > and with the 64-bit guest I get this error as well (recall the guest > > > fails to boot on 64-bit) > > > > > > BUG: kvm_dirty_pages_log_change: invalid parameters > > > 00000000f0000000-00000000f0ffffff > > > > > > diff --git a/src/pciinit.c b/src/pciinit.c > > index b110531..6eca2ce 100644 > > --- a/src/pciinit.c > > +++ b/src/pciinit.c > > @@ -90,7 +90,8 @@ static int pci_bios_allocate_region(u16 bdf, int region_num) > > /* If pci_bios_prefmem_addr == 0, keep old behaviour */ > > pci_bios_prefmem_addr != 0) { > > paddr = &pci_bios_prefmem_addr; > > - if (ALIGN(*paddr, size) + size >= BUILD_PCIPREFMEM_END) { > > + if (ALIGN(*paddr, size) + size < *paddr || > > + ALIGN(*paddr, size) + size >= BUILD_PCIPREFMEM_END) { > > dprintf(1, > > "prefmem region of (bdf 0x%x bar %d) can't be mapped. " > > "decrease BUILD_PCIMEM_SIZE and recompile. size %x\n", > > @@ -99,7 +100,8 @@ static int pci_bios_allocate_region(u16 bdf, int region_num) > > } > > } else { > > paddr = &pci_bios_mem_addr; > > - if (ALIGN(*paddr, size) + size >= BUILD_PCIMEM_END) { > > + if (ALIGN(*paddr, size) + size < *paddr || > > + ALIGN(*paddr, size) + size >= BUILD_PCIMEM_END) { > > dprintf(1, > > "mem region of (bdf 0x%x bar %d) can't be mapped. " > > "increase BUILD_PCIMEM_SIZE and recompile. size %x\n", > > Looking at the source, all of the values like pci_bios_prefmem_addr seem to be > 32 bit. Since in the spec prefetcheable memory is up to 64 bit, > can't the math overflow, here and elsewhere? > Maybe we should switch to 64 bit values all over ... Make sense. I'll create a patch to convert them into u64. > > > @@ -116,12 +118,8 @@ static int pci_bios_allocate_region(u16 bdf, int region_num) > > > > int is_64bit = !(val & PCI_BASE_ADDRESS_SPACE_IO) && > > (val & PCI_BASE_ADDRESS_MEM_TYPE_MASK) == PCI_BASE_ADDRESS_MEM_TYPE_64; > > - if (is_64bit) { > > - if (size > 0) { > > - pci_config_writel(bdf, ofs + 4, 0); > > - } else { > > - pci_config_writel(bdf, ofs + 4, ~0); > > - } > > + if (is_64bit && size > 0) { > > + pci_config_writel(bdf, ofs + 4, 0); > > } > > return is_64bit; > > } > > > Was there any reason we wrote all-ones there on size 0? > BAR sizing? No reason. It's just left over from debugging. So I'd like to remove it. -- yamahata

2 4

[PATCH] Update qemu_cfg_read to use "rep insb".
by Kevin O'Connor 26 Aug '10

26 Aug '10

Use rep insb instead of manual loop - the host may be able to optimize the rep insb instruction. --- src/paravirt.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/src/paravirt.c b/src/paravirt.c index da72c71..ca646d4 100644 --- a/src/paravirt.c +++ b/src/paravirt.c @@ -24,8 +24,7 @@ qemu_cfg_select(u16 f) static void qemu_cfg_read(u8 *buf, int len) { - while (len--) - *(buf++) = inb(PORT_QEMU_CFG_DATA); + insb(PORT_QEMU_CFG_DATA, buf, len); } static void -- 1.7.2.2

1 0

[PATCH] Only show bootsplash during boot menu.
by Kevin O'Connor 26 Aug '10

26 Aug '10

Only show bootsplash during boot menu. When the bootsplash picture is shown, it's not possible to see text. So, only display the picture while prompting the user for the boot menu. diff --git a/src/biosvar.h b/src/biosvar.h index 415f958..2b755e3 100644 --- a/src/biosvar.h +++ b/src/biosvar.h @@ -222,7 +222,6 @@ struct extended_bios_data_area_s { u8 other2[0xC4]; // 0x121 - Begin custom storage. - u8 bootsplash_active; u8 ps2ctr; struct usbkeyinfo usbkey_last; diff --git a/src/boot.c b/src/boot.c index 44964a7..021b8ac 100644 --- a/src/boot.c +++ b/src/boot.c @@ -227,7 +227,9 @@ interactive_bootmenu(void) printf("Press F12 for boot menu.\n\n"); + enable_bootsplash(); int scan_code = get_keystroke(CONFIG_BOOTMENU_WAIT); + disable_bootsplash(); if (scan_code != 0x86) /* not F12 */ return; @@ -343,9 +345,6 @@ boot_prep(void) static void call_boot_entry(u16 bootseg, u16 bootip, u8 bootdrv) { - /* Go back to text, the OS might expect it... (Can't do this any later) */ - disable_bootsplash(); - dprintf(1, "Booting from %04x:%04x\n", bootseg, bootip); struct bregs br; memset(&br, 0, sizeof(br)); @@ -430,7 +429,6 @@ boot_cbfs(struct ipl_entry_s *ie) return; if (count--) continue; - disable_bootsplash(); cbfs_run_payload(file); } } diff --git a/src/bootsplash.c b/src/bootsplash.c index 14bdd4c..8f42dfd 100644 --- a/src/bootsplash.c +++ b/src/bootsplash.c @@ -92,8 +92,8 @@ call16_int10(struct bregs *br) * VGA text / graphics console ****************************************************************/ -static void -enable_vga_text_console(void) +void +enable_vga_console(void) { dprintf(1, "Turning on vga text mode console\n"); struct bregs br; @@ -141,29 +141,27 @@ find_videomode(struct vesa_info *vesa_info, struct vesa_mode_info *mode_info } } +static int BootsplashActive; + void -enable_vga_console(void) +enable_bootsplash(void) { - struct vesa_info *vesa_info = NULL; - struct vesa_mode_info *mode_info = NULL; - struct jpeg_decdata *jpeg = NULL; - u8 *filedata = NULL, *picture = NULL; - if (!CONFIG_BOOTSPLASH) - goto gotext; + return; dprintf(3, "Checking for bootsplash\n"); u32 file = romfile_find("bootsplash.jpg"); if (!file) - goto gotext; + return; int filesize = romfile_size(file); - filedata = malloc_tmphigh(filesize); - vesa_info = malloc_tmplow(sizeof(*vesa_info)); - mode_info = malloc_tmplow(sizeof(*mode_info)); - jpeg = jpeg_alloc(); + u8 *picture = NULL; + u8 *filedata = malloc_tmphigh(filesize); + struct vesa_info *vesa_info = malloc_tmplow(sizeof(*vesa_info)); + struct vesa_mode_info *mode_info = malloc_tmplow(sizeof(*mode_info)); + struct jpeg_decdata *jpeg = jpeg_alloc(); if (!filedata || !jpeg || !vesa_info || !mode_info) { warn_noalloc(); - goto gotext; + goto done; } /* Check whether we have a VESA 2.0 compliant BIOS */ @@ -177,7 +175,7 @@ enable_vga_console(void) call16_int10(&br); if (vesa_info->vesa_signature != VESA_SIGNATURE) { dprintf(1,"No VBE2 found.\n"); - goto gotext; + goto done; } /* Print some debugging information about our card. */ @@ -194,7 +192,7 @@ enable_vga_console(void) int ret = jpeg_decode(jpeg, filedata); if (ret) { dprintf(1, "jpeg_decode failed with return code %d...\n", ret); - goto gotext; + goto done; } int width, height; jpeg_get_size(jpeg, &width, &height); @@ -202,7 +200,7 @@ enable_vga_console(void) // Try to find a graphics mode with the corresponding dimensions. int videomode = find_videomode(vesa_info, mode_info, width, height); if (videomode < 0) - goto gotext; + goto done; void *framebuffer = mode_info->phys_base_ptr; int depth = mode_info->bits_per_pixel; dprintf(3, "mode: %04x\n", videomode); @@ -215,13 +213,13 @@ enable_vga_console(void) picture = malloc_tmphigh(imagesize); if (!picture) { warn_noalloc(); - goto gotext; + goto done; } dprintf(5, "Decompressing bootsplash.jpg\n"); ret = jpeg_show(jpeg, picture, width, height, depth); if (ret) { dprintf(1, "jpeg_show failed with return code %d...\n", ret); - goto gotext; + goto done; } /* Switch to graphics mode */ @@ -232,32 +230,29 @@ enable_vga_console(void) call16_int10(&br); if (br.ax != 0x4f) { dprintf(1, "set_mode failed.\n"); - goto gotext; + goto done; } /* Show the picture */ dprintf(5, "Showing bootsplash.jpg\n"); iomemcpy(framebuffer, picture, imagesize); dprintf(5, "Bootsplash copy complete\n"); - SET_EBDA(bootsplash_active, 1); + BootsplashActive = 1; -cleanup: +done: free(filedata); free(picture); free(vesa_info); free(mode_info); free(jpeg); return; -gotext: - enable_vga_text_console(); - goto cleanup; } void disable_bootsplash(void) { - if (!CONFIG_BOOTSPLASH || !GET_EBDA(bootsplash_active)) + if (!CONFIG_BOOTSPLASH || !BootsplashActive) return; - SET_EBDA(bootsplash_active, 0); - enable_vga_text_console(); + BootsplashActive = 0; + enable_vga_console(); } diff --git a/src/post.c b/src/post.c index 56e5eb5..5d0e2cb 100644 --- a/src/post.c +++ b/src/post.c @@ -265,10 +265,6 @@ _start(void) // Write protect bios memory. make_bios_readonly(); - // Disable bootsplash if something has hooked int19. - if (GET_IVT(0x19).segoff != FUNC16(entry_19_official).segoff) - disable_bootsplash(); - // Invoke int 19 to start boot process. dprintf(3, "Jump to int19\n"); struct bregs br; diff --git a/src/util.h b/src/util.h index 45896c6..3d68d45 100644 --- a/src/util.h +++ b/src/util.h @@ -383,6 +383,7 @@ extern u32 RomEnd; // bootsplash.c void enable_vga_console(void); +void enable_bootsplash(void); void disable_bootsplash(void); // resume.c

1 0

[PATCHv3] add write support to virtio-blk
by Gleb Natapov 24 Aug '10

24 Aug '10

Windows XP does write to sector 0 during installation and prints mysterious error if write fails. Interestingly if write drops data, but returns OK to Windows installer installation proceed without complains and completes successfully. Signed-off-by: Gleb Natapov <gleb(a)redhat.com> --- v1->v2 Call to vring_add_buf() should be different for write and read. v2->v3 Return success on CMD_FORMAT. diff --git a/src/virtio-blk.c b/src/virtio-blk.c index 74af488..34d7863 100644 --- a/src/virtio-blk.c +++ b/src/virtio-blk.c @@ -26,13 +26,13 @@ struct virtiodrive_s { }; static int -virtio_blk_read(struct disk_op_s *op) +virtio_blk_op(struct disk_op_s *op, int write) { struct virtiodrive_s *vdrive_g = container_of(op->drive_g, struct virtiodrive_s, drive); struct vring_virtqueue *vq = GET_GLOBAL(vdrive_g->vq); struct virtio_blk_outhdr hdr = { - .type = VIRTIO_BLK_T_IN, + .type = write ? VIRTIO_BLK_T_OUT : VIRTIO_BLK_T_IN, .ioprio = 0, .sector = op->lba, }; @@ -53,7 +53,10 @@ virtio_blk_read(struct disk_op_s *op) }; /* Add to virtqueue and kick host */ - vring_add_buf(vq, sg, 1, 2, 0, 0); + if (write) + vring_add_buf(vq, sg, 2, 1, 0, 0); + else + vring_add_buf(vq, sg, 1, 2, 0, 0); vring_kick(GET_GLOBAL(vdrive_g->ioaddr), vq, 1); /* Wait for reply */ @@ -78,10 +81,10 @@ process_virtio_op(struct disk_op_s *op) return 0; switch (op->command) { case CMD_READ: - return virtio_blk_read(op); - case CMD_FORMAT: + return virtio_blk_op(op, 0); case CMD_WRITE: - return DISK_RET_EWRITEPROTECT; + return virtio_blk_op(op, 1); + case CMD_FORMAT: case CMD_RESET: case CMD_ISREADY: case CMD_VERIFY: -- Gleb.

2 1

Running out of space in e/f-segments
by Kevin O'Connor 23 Aug '10

23 Aug '10

SeaBIOS is coming close to exceeding 128K in size. Right now, it's approximately 107K on qemu with default options and 120K with full debugging and all options enabled. SeaBIOS currently contends with option roms for space. Every byte that SeaBIOS uses is one less byte available for option roms. It's technically possible for SeaBIOS to exceed 128K, but it's likely that we'll start seeing option roms not fitting around that point. It would also be nice to be able to do malloc_low allocations from the e-segment. This too requires freeing up space that SeaBIOS is currently using to store code. I've been thinking of a few different ways to free up space. The most promising approach seems to be to relocate all or part of SeaBIOS' 32bit "flat" code. This 32bit code is larger than the segmented code (67K vs 40K) and it's the area that has been growing the most. To relocate the code, the build can store a list of code that depends on a fixed address and then at runtime SeaBIOS can modify the code with the new address. Some different permutations of this idea that I've come up with are: 1 - On boot, have SeaBIOS relocate all of it's 32bit code to permanent high ram. CONS: Reserves memory that then can't be used by the OS (67K today). CONS: SeaBIOS code is still limited to 256K size (c+d+e+f segments) 2 - Have the build separate out the POST code from other 32bit code (eg, boot & resume) and store the POST code in a separate CBFS/fw_cfg "file". During boot SeaBIOS would extract the separate POST code blob into temporary high ram and run it. Currently, the POST code is the bulk of the 32bit "flat" code (57K vs 10K). CONS: It adds complexity during deployment as both the main SeaBIOS blob and the CBFS/fw_cfg POST blob would need to be copied. 3 - On boot, relocate only POST code to temporary high ram, and have SeaBIOS reset the machine if the POST code is ever rerun. CONS: Requires a reliable way of resetting the machine. CONS: SeaBIOS code is still limited to 256K size (c+d+e+f segments) Any thoughts? I kinda prefer option 3. Resetting the machine on a rerun of POST would be a good thing to do anyway, as trying to re-post the machine has never really worked well. It does, however, make the build a bit more complex. -Kevin

6 26

[PATCH] add write support to virtio-blk
by Gleb Natapov 21 Aug '10

21 Aug '10

Windows XP needs it during installation. Signed-off-by: Gleb Natapov <gleb(a)redhat.com> diff --git a/src/virtio-blk.c b/src/virtio-blk.c index 74af488..91277f4 100644 --- a/src/virtio-blk.c +++ b/src/virtio-blk.c @@ -26,13 +26,13 @@ struct virtiodrive_s { }; static int -virtio_blk_read(struct disk_op_s *op) +virtio_blk_op(struct disk_op_s *op, int write) { struct virtiodrive_s *vdrive_g = container_of(op->drive_g, struct virtiodrive_s, drive); struct vring_virtqueue *vq = GET_GLOBAL(vdrive_g->vq); struct virtio_blk_outhdr hdr = { - .type = VIRTIO_BLK_T_IN, + .type = write ? VIRTIO_BLK_T_OUT : VIRTIO_BLK_T_IN, .ioprio = 0, .sector = op->lba, }; @@ -78,9 +78,10 @@ process_virtio_op(struct disk_op_s *op) return 0; switch (op->command) { case CMD_READ: - return virtio_blk_read(op); - case CMD_FORMAT: + return virtio_blk_op(op, 0); case CMD_WRITE: + return virtio_blk_op(op, 1); + case CMD_FORMAT: return DISK_RET_EWRITEPROTECT; case CMD_RESET: case CMD_ISREADY: -- Gleb.

2 4

[PATCH] Don't try to talk to APIC on 486
by Lubomir Rintel 21 Aug '10

21 Aug '10

It only has one cpuid level, therefore it can't report whether it has an APIC. It probably hasn't; assume that. Without this, SeaBIOS would get stuck on qemu -M isapc. Signed-off-by: Lubomir Rintel <lkundrak(a)v3.sk> --- src/smp.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/smp.c b/src/smp.c index f989ec1..38e117e 100644 --- a/src/smp.c +++ b/src/smp.c @@ -72,7 +72,7 @@ smp_probe(void) ASSERT32FLAT(); u32 eax, ebx, ecx, cpuid_features; cpuid(1, &eax, &ebx, &ecx, &cpuid_features); - if (! (cpuid_features & CPUID_APIC)) { + if (eax < 1 || !(cpuid_features & CPUID_APIC)) { // No apic - only the main cpu is present. dprintf(1, "No apic - only the main cpu is present.\n"); CountCPUs= 1; -- 1.7.2.1

2 1

Re: [SeaBIOS] [PATCH] seabios: acpi: add mcfg table.
by Kevin O'Connor 19 Aug '10

19 Aug '10

On Fri, Jul 30, 2010 at 11:51:58AM +0900, Isaku Yamahata wrote: > add mcfg table. > mcfg isn't populated at the moment. dev-q35 will use it later. This patch slipped through the cracks - sorry. This patch doesn't seem to do much right now as no IDs are defined. It looks like it is in preparation for follow up patches. However, I don't think it's possible to really judge this patch without seeing the follow up ones. -Kevin

2 1

[PATCH 1/2] Split region allocation code from pci_bios_init_device()
by Eduard - Gabriel Munteanu 18 Aug '10

18 Aug '10

pci_bios_alloc() can be used to allocate space in the PCI region for other purposes. This is needed by the AMD IOMMU support code. Signed-off-by: Eduard - Gabriel Munteanu <eduard.munteanu(a)linux360.ro> --- src/pciinit.c | 17 +++++++++++++---- 1 files changed, 13 insertions(+), 4 deletions(-) diff --git a/src/pciinit.c b/src/pciinit.c index 0556ee2..bfc669f 100644 --- a/src/pciinit.c +++ b/src/pciinit.c @@ -75,6 +75,16 @@ static void pci_bios_init_bridges(u16 bdf) } } +static inline u32 pci_bios_alloc(u32 *region, u32 size) +{ + u32 ret; + + ret = ALIGN(*region, size); + *region = ret + size; + + return ret; +} + static void pci_bios_init_device(u16 bdf) { int class; @@ -146,14 +156,13 @@ static void pci_bios_init_device(u16 bdf) pci_config_writel(bdf, ofs, old); if (val != 0) { - u32 size = (~(val & mask)) + 1; + u32 base, size = (~(val & mask)) + 1; if (val & PCI_BASE_ADDRESS_SPACE_IO) paddr = &pci_bios_io_addr; else paddr = &pci_bios_mem_addr; - *paddr = ALIGN(*paddr, size); - pci_set_io_region_addr(bdf, i, *paddr); - *paddr += size; + base = pci_bios_alloc(paddr, size); + pci_set_io_region_addr(bdf, i, base); } } break; -- 1.7.1

2 2

Re: [SeaBIOS] [PATCH] Fix bug for vcpu hotplug
by Avi Kivity 15 Aug '10

15 Aug '10

On 08/06/2010 06:36 AM, Liu, Jinsong wrote: > Recently seabios implement vcpu hotplug infrastructure. > During test, we found qemu-kvm has a bug result in guestos shutdown when vcpu hotadd. > This patch is to fix the bug, mark bus->allow_hotplug as 1 after qdev_hotplug init done. Please copy qemu-devel on qemu patches. > @@ -117,6 +117,9 @@ DeviceState *qdev_create(BusState *bus, const char *name) > hw_error("Unknown device '%s' for bus '%s'\n", name, bus->info->name); > } > > + if (qdev_hotplug) > + bus->allow_hotplug = 1; > + > return qdev_create_from_info(bus, info); > } Doesn't seem right - this will set allow_hotplug on all busses. It needs to be set only on the system bus (hw/sysbus.c). -- error compiling committee.c: too many arguments to function

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS