This patch gets rid of a compile time dprintf warning.
A 'long int' was being passed to a '%d'.
Signed-off-by: Dave Frodin <dave.frodin(a)se-eng.com>
---
src/post.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/post.c b/src/post.c
index 924b311..b84d19e 100644
--- a/src/post.c
+++ b/src/post.c
@@ -345,7 +345,7 @@ reloc_init(void)
panic("No space for init relocation.\n");
// Copy code and update relocs (init absolute, init relative, and runtime)
- dprintf(1, "Relocating low data from %p to %p (size %d)\n"
+ dprintf(1, "Relocating low data from %p to %p (size %ld)\n"
, datalow_start, final_datalow_start, datalow_end - datalow_start);
updateRelocs(code32flat_start, _reloc_datalow_start, _reloc_datalow_end
, final_datalow_start - datalow_start);
--
1.7.9
Makes the config less confusing as we don't have to
use "!COREBOOT" if we wanna say "QEMU".
Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com>
---
src/Kconfig | 32 +++++++++++++++++++++-----------
1 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/src/Kconfig b/src/Kconfig
index b5dd63b..ee6fdb6 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -4,14 +4,24 @@ mainmenu "SeaBIOS Configuration"
menu "General Features"
+choice
+ prompt "Build Target"
+ default QEMU
+
config COREBOOT
bool "Build for coreboot"
- default n
help
Configure as a coreboot payload.
+ config QEMU
+ bool "Build for QEMU"
+ help
+ Configure as QEMU bios.
+
+endchoice
+
config XEN
- depends on !COREBOOT
+ depends on QEMU
bool "Build for Xen HVM"
default y
help
@@ -108,25 +118,25 @@ menu "Hardware support"
help
Support for AHCI disk code.
config VIRTIO_BLK
- depends on DRIVES && !COREBOOT
+ depends on DRIVES && QEMU
bool "virtio-blk controllers"
default y
help
Support boot from virtio-blk storage.
config VIRTIO_SCSI
- depends on DRIVES && !COREBOOT
+ depends on DRIVES && QEMU
bool "virtio-scsi controllers"
default y
help
Support boot from virtio-scsi storage.
config ESP_SCSI
- depends on DRIVES && !COREBOOT
+ depends on DRIVES && QEMU
bool "AMD PCscsi controllers"
default y
help
Support boot from AMD PCscsi storage.
config LSI_SCSI
- depends on DRIVES && !COREBOOT
+ depends on DRIVES && QEMU
bool "lsi53c895a scsi controllers"
default y
help
@@ -211,19 +221,19 @@ menu "Hardware support"
Support parallel ports. This also enables int 17 parallel port calls.
config USE_SMM
- depends on !COREBOOT
+ depends on QEMU
bool "System Management Mode (SMM)"
default y
help
Support System Management Mode (on emulators).
config MTRR_INIT
- depends on !COREBOOT
+ depends on QEMU
bool "Initialize MTRRs"
default y
help
Initialize the Memory Type Range Registers (on emulators).
config PMTIMER
- depends on !COREBOOT
+ depends on QEMU
bool "Use ACPI timer"
default y
help
@@ -327,7 +337,7 @@ menu "BIOS interfaces"
endmenu
menu "BIOS Tables"
- depends on !COREBOOT
+ depends on QEMU
config PIRTABLE
bool "PIR table"
default y
@@ -377,7 +387,7 @@ menu "Debugging"
Base port for serial - generally 0x3f8, 0x2f8, 0x3e8, or 0x2e8.
config DEBUG_IO
- depends on !COREBOOT && DEBUG_LEVEL != 0
+ depends on QEMU && DEBUG_LEVEL != 0
bool "Special IO port debugging"
default y
help
--
1.7.1
On Thu, Oct 18, 2012 at 12:25:58PM +0200, Christian Gmeiner wrote:
> 2012/10/17 Kevin O'Connor <kevin(a)koconnor.net>:
> > The controller is supposed to update the toggle bit in the qh. The
> > same qh is used for all transfers, so it should already be up to date
> > between transfers. It is possible something subtle is going on here.
>
> USB is finally working :) http://dpaste.com/815054/
Great! Can you post the EHCI patch you used to make this work?
Thanks,
-Kevin
On 10/31/2012 12:58 PM, Stefan Hajnoczi wrote:
> On Fri, Sep 21, 2012 at 1:17 PM, Vasilis Liaskovitis
> <vasilis.liaskovitis(a)profitbricks.com> wrote:
>> This is v3 of the ACPI memory hotplug functionality. Only x86_64 target is supported
>> for now.
>
> Hi Vasilis,
> Regarding the hot unplug issue we've been discussing, it's possible to
> progress this patch series without fully solving that problem upfront.
>
> Karen Noel suggested that the series could be rolled without the hot
> unplug command, so that it's not possible to hit the unsafe case.
> This would allow users to hot plug additional memory. They would have
> to use virtio-balloon to reduce the memory footprint again. Later,
> when the memory region referencing issue has been solved the hot
> unplug command can be added.
>
> Just wanted to mention Karen's idea in case you feel stuck right now.
We could introduce hotunplug as an experimental feature so people can
test and play with it, and later graduate it to a fully supported feature.
--
error compiling committee.c: too many arguments to function
On 10/31/2012 02:18 PM, Stefan Hajnoczi wrote:
>>
>> IMO we should use the same mechanism as proposed for other devices:
>> address_space_map() should grab a reference on the dimm device, and
>> address_space_unmap() can release it. This way device destruction will
>> be deferred as soon as all devices complete I/O.
>>
>> We will have to be careful with network receive buffers though, since
>> they can be held indefinitely.
>
> Network receive buffers aren't mapped. Net receive is not zero-copy.
> For example, virtio-net does virtqueue_pop() inside
> virtio_net_receive().
>
> I don't see a problem with networking.
What about vhost-net? But that is managed separately with a MemoryListener.
--
error compiling committee.c: too many arguments to function
On 10/24/2012 10:06 AM, liu ping fan wrote:
> On Tue, Oct 23, 2012 at 8:25 PM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote:
>> On Fri, Sep 21, 2012 at 01:17:21PM +0200, Vasilis Liaskovitis wrote:
>>> +static void dimm_populate(DimmDevice *s)
>>> +{
>>> + DeviceState *dev= (DeviceState*)s;
>>> + MemoryRegion *new = NULL;
>>> +
>>> + new = g_malloc(sizeof(MemoryRegion));
>>> + memory_region_init_ram(new, dev->id, s->size);
>>> + vmstate_register_ram_global(new);
>>> + memory_region_add_subregion(get_system_memory(), s->start, new);
>>> + s->mr = new;
>>> +}
>>> +
>>> +static void dimm_depopulate(DimmDevice *s)
>>> +{
>>> + assert(s);
>>> + vmstate_unregister_ram(s->mr, NULL);
>>> + memory_region_del_subregion(get_system_memory(), s->mr);
>>> + memory_region_destroy(s->mr);
>>> + s->mr = NULL;
>>> +}
>>
>> How is dimm hot unplug protected against callers who currently have RAM
>> mapped (from cpu_physical_memory_map())?
>>
>> Emulated devices call cpu_physical_memory_map() directly or indirectly
>> through DMA emulation code. The RAM pointer may be held for arbitrary
>> lengths of time, across main loop iterations, etc.
>>
>> It's not clear to me that it is safe to unplug a DIMM that has network
>> or disk I/O buffers, for example. We also need to be robust against
>> malicious guests who abuse the hotplug lifecycle. QEMU should never be
>> left with dangling pointers.
>>
> Not sure about the block layer. But I think those thread are already
> out of big lock, so there should be a MemoryListener to catch the
> RAM-unplug event, and if needed, bdrv_flush.
IMO we should use the same mechanism as proposed for other devices:
address_space_map() should grab a reference on the dimm device, and
address_space_unmap() can release it. This way device destruction will
be deferred as soon as all devices complete I/O.
We will have to be careful with network receive buffers though, since
they can be held indefinitely.
--
error compiling committee.c: too many arguments to function
On Fri, Sep 21, 2012 at 1:17 PM, Vasilis Liaskovitis
<vasilis.liaskovitis(a)profitbricks.com> wrote:
> This is v3 of the ACPI memory hotplug functionality. Only x86_64 target is supported
> for now.
Hi Vasilis,
Regarding the hot unplug issue we've been discussing, it's possible to
progress this patch series without fully solving that problem upfront.
Karen Noel suggested that the series could be rolled without the hot
unplug command, so that it's not possible to hit the unsafe case.
This would allow users to hot plug additional memory. They would have
to use virtio-balloon to reduce the memory footprint again. Later,
when the memory region referencing issue has been solved the hot
unplug command can be added.
Just wanted to mention Karen's idea in case you feel stuck right now.
Stefan
hi all:
Does anyone know that if seabiso support booting from other disk if boot
from one failed ?
For instance, the PC BIOS boot specification allows only one
disk to be bootable. If boot from disk fails for some reason, the BIOS
won't retry booting from other disk. It still can try to boot from
floppy or net, though.I want to know that if seabios support retry booting from other disk?
Thanks Eli.
