On 09/04/2015 18:58, Kevin O'Connor wrote:
Is it worth keeping the definition in src/x86.h?
Thanks for reviewing.
It could be removed, but I was thinking of leaving it in. It's always
a pain getting the parameters of gcc inline assembler correct and it
might be useful for some future
On 09/04/2015 18:37, Kevin O'Connor wrote:
Commit 251e2638 introduced the smsww instruction to the vgabios.
Unfortunately, it appears at least some versions of x86emu crash when
executing that instruction (eg, FC13 installer crashes). That
instruction wasn't required to work around the
On 24/03/2015 17:22, Bruce Rogers wrote:
All,
When building SeaBIOS in the context of QEMU v2.3-rc0 using
various openSUSE versions we found that some recent versions
overflowed the 128K limit imposed for bios.bin. The Makefile
fails with the suggestion of using a more recent toolset or
Patch 1 applies a small improvement to user experience, as suggested
by Matt DeVillier. Then patch 2 makes the switch.
Paolo Bonzini (2):
boot: delay exiting boot if menu key is ESC
boot: switch default menu key to ESC
src/boot.c | 12 +---
1 file changed, 9 insertions(+), 3
...@gmail.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
src/boot.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/boot.c b/src/boot.c
index f23e9e1..3aab8d4 100644
--- a/src/boot.c
+++ b/src/boot.c
@@ -486,9 +486,15 @@ interactive_bootmenu(void
function keys are usually trapped by terminals.
Hence, using ESC for the boot menu avoids the problems associated
with F12.
Suggested-by: Kevin O'Connor ke...@koconnor.net
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
src/boot.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On 12/03/2015 16:58, Matt DeVillier wrote:
Is there are reason to keep the use of ESC to exit the boot menu at
all?
It's a fairly obvious user interface. If you don't know what to choose,
press ESC.
Is that a feature that users use/expect? 1.5s may sound like a
lot of time, but with many
function keys are usually trapped by terminals.
Hence, using ESC for the boot menu avoids the problems associated
with F12.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
docs/Runtime_config.md | 4 ++--
src/boot.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git
Patch 1 applies a small improvement to user experience, as suggested
by Matt DeVillier. Then patch 2 makes the switch.
v3-v4: also update docs/Runtime_config.md.
Paolo Bonzini (2):
boot.c: delay exiting boot if menu key is ESC
boot: switch default menu key to ESC
docs/Runtime_config.md
On 11/03/2015 17:09, Kevin O'Connor wrote:
But more important, which keys are and are not available depends on the
client, not on the server. So for VNC all keys work but on at least a
viewer F8 is inconvenient because it brings up a menu (thankfully one
item in the menu is Send F8); for
On 11/03/2015 18:24, Kevin O'Connor wrote:
On Wed, Mar 11, 2015 at 05:42:18PM +0100, Paolo Bonzini wrote:
I have no problem with changing the key; the problem I have with ESC is
that I'm going to add F12 for network boot, and then I would like ESC+@
to trigger network boot. ESC for the boot
=
KVM Forum 2015: Call For Participation
August 19-21, 2015 - Sheraton Seattle - Seattle, WA
(All submissions must be received before midnight May 1, 2015)
=
KVM is an
=
KVM Forum 2015: Call For Participation
August 19-21, 2015 - Sheraton Seattle - Seattle, WA
(All submissions must be received before midnight May 1, 2015)
=
KVM is an
On 05/03/2015 10:27, Paolo Bonzini wrote:
F11 and F12 are trapped by some terminal emulators, and sgabios does
not always recognize function keys very well.
Real-world machines often provide replacements for function keys for
use on the serial console: ESC+1...ESC+0 for F1...F10, ESC+SHIFT
On 04/03/2015 22:42, Kevin O'Connor wrote:
On Wed, Mar 04, 2015 at 05:57:02PM +0100, Paolo Bonzini wrote:
F11 and F12 are trapped by some terminal emulators, and sgabios does
not always recognize function keys very well.
Real-world machines often provide replacements for function keys
of them, which can be useful in
case the user has set boot-menu-key.
The behavior is disabled if ESC is configured to trigger the menu.
Chromebooks use this configuration.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
v1-v2: disable new behavior if ESC triggers the boot menu [Kevin
of them, which can be useful in
case the user has set boot-menu-key.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
src/boot.c | 52 +++-
1 file changed, 47 insertions(+), 5 deletions(-)
diff --git a/src/boot.c b/src/boot.c
index f23e9e1..3f1ea4a
of them, which can be useful in
case the user has set boot-menu-key.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
src/boot.c | 52 +++-
1 file changed, 47 insertions(+), 5 deletions(-)
diff --git a/src/boot.c b/src/boot.c
index f23e9e1..3f1ea4a
On 06/02/2015 22:13, Timothy Pearson wrote:
+config CBFS_OPTIONROMS_ONLY
+depends on OPTIONROMS
Probably depends on OPTIONROMS COREBOOT_FLASH is better.
Paolo
+bool Only execute option ROMs stored in CBFS
+default n
+help
On 13/01/2015 15:30, Peter Stuge wrote:
That would be pretty slow on KVM, since video memory is MMIO.
slow reliable fast unreliable
But worse, one could imagine that NTVDM blocks a-b as well.
I doubt that? Then how would the VGA BIOS write its data?
The question is more why
On 13/01/2015 13:26, Peter Stuge wrote:
I can think of a few options:
7 - use top of video memory as stack?
That would be pretty slow on KVM, since video memory is MMIO. But
worse, one could imagine that NTVDM blocks a-b as well.
Paolo
On 12/01/2015 16:59, Richard Laager wrote:
On Mon, 2015-01-12 at 10:32 -0500, Kevin O'Connor wrote:
Interesting. Does your original business app then also work with
CONFIG_VGA_ALLOCATE_EXTRA_STACK disabled?
Yes. I couldn't be sure if I tested before, since I didn't write it
down. But I
No, KVM hides the fact that you are in protected mode. EMM386 would be
affected, but then it is not impossible for old programs to require
disabling it.
I was under the vague impression that kvm uses VM86 mode to run 16bit
code on some Intel chipsets. The SMSW instruction isn't
On 12/01/2015 20:36, Kevin O'Connor wrote:
Okay, so it fakes real-mode by setting up a protected mode guest with
a fake CR0 that is running vm86, and so SMSW still returns a value
with PE off? (As opposed to a regular guest that itself launches a
VM86 instance, in which case CR0 from SMSW
On 12/01/2015 19:19, Kevin O'Connor wrote:
I was able to reproduce this locally with 16bit skifree on Windows
Vista. (Interestingly, the problem doesn't occur on winxp.)
I put there is a 16-bit freely downloadable version of skifree on my
personal list of trivia that ended up becoming
On 07/01/2015 07:43, Kevin O'Connor wrote:
So, unless I've missed something, I don't think it impacts gwbasic.
Yeah, I don't know how I missed if (vga_emulate_text()). I guess I
was confused by the reference to other video cards in the commit messages.
Paolo
On 06/01/2015 16:49, Kevin O'Connor wrote:
+if (vga_emulate_text()) {
+// Read bottom right pixel of the cell to guess bg color
+op.y += cheight-1;
+handle_gfx_op(op);
+op.y -= cheight-1;
+bgattr = op.pixels[7];
+fgattr = bgattr ^ 0x7;
On 06/01/2015 20:59, Paolo Bonzini wrote:
On 06/01/2015 16:49, Kevin O'Connor wrote:
+if (vga_emulate_text()) {
+// Read bottom right pixel of the cell to guess bg color
+op.y += cheight-1;
+handle_gfx_op(op);
+op.y -= cheight-1;
+bgattr
On 06/01/2015 20:59, Paolo Bonzini wrote:
On 06/01/2015 16:49, Kevin O'Connor wrote:
+if (vga_emulate_text()) {
+// Read bottom right pixel of the cell to guess bg color
+op.y += cheight-1;
+handle_gfx_op(op);
+op.y -= cheight-1;
+bgattr
On 06/01/2015 21:22, Kevin O'Connor wrote:
On Tue, Jan 06, 2015 at 08:59:09PM +0100, Paolo Bonzini wrote:
On 06/01/2015 16:49, Kevin O'Connor wrote:
+if (vga_emulate_text()) {
+// Read bottom right pixel of the cell to guess bg color
+op.y += cheight-1
On 02/01/2015 18:43, Kevin O'Connor wrote:
On Thu, Jan 01, 2015 at 09:27:47PM +0100, Paolo Bonzini wrote:
GWBasic relies on this, so implement it to enable some serious
retrocomputing.
There is no better way to do it than trying to match all characters one by
one
against the current font
On 02/01/2015 04:40, Kevin O'Connor wrote:
I couldn't find documentation for what to return as the attribute, but
experimenting with DOSBox suggests 0 (and GWBasic accepts it).
Just for reference, for the cbvga text mode emulation, I grab the
background attribute by assuming the lower
On 02/01/2015 04:10, Kevin O'Connor wrote:
On Thu, Jan 01, 2015 at 09:27:46PM +0100, Paolo Bonzini wrote:
For legacy VGA modes that do not set the VBE_DISPI_ENABLED bit,
bochsvga_get_linelength returns 0. Thus all characters are squashed
into the first scanline. Fix this by falling back
For legacy VGA modes that do not set the VBE_DISPI_ENABLED bit,
bochsvga_get_linelength returns 0. Thus all characters are squashed
into the first scanline. Fix this by falling back to stdvga for
the legacy modes.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
vgasrc/bochsvga.c | 27
in the programs but not in direct mode).
I couldn't find documentation for what to return as the attribute, but
experimenting with DOSBox suggests 0 (and GWBasic accepts it).
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
vgasrc/vgafb.c | 41 ++---
1 file
Il 02/10/2014 22:35, Kevin O'Connor ha scritto:
On kvm, I think the easiest would be to get psuedo smm support
working in kvm.
That's on the todo list.
Not sure the best way to do it on CSM.
There's support for that; OVMF needs to provide an SmmInit hook. It
probably would map into an
Il 02/10/2014 21:38, Paolo Bonzini ha scritto:
+config CALL32_SMM
+bool
+depends on USE_SMM
+default y
I think it is a bit too early to make this the default.
Nevermind, I cannot read C.
Paolo
___
SeaBIOS mailing
Il 15/08/2014 08:58, Markus Armbruster ha scritto:
No actual impact on USB, because QEMU only uses LUN 0 there.
With usb-bot, you can actually add multiple LUNs to QEMU, up to LUN 15.
(USB Attached SCSI supports LUNs up to 255). Still it's a very rare case.
Paolo
Il 30/06/2014 15:11, Ian Campbell ha scritto:
On Mon, 2014-06-30 at 15:07 +0200, Paolo Bonzini wrote:
Il 30/06/2014 15:03, Ian Campbell ha scritto:
That line is:
// Acquire lock and take ownership of shared stack
1: rep nop
I've also checked the preprocessed
---
Changed since v2:
* Use lock btsl instead of lock cmpxchgl as suggested by Paolo.
* Enable CPU caching on the APs
* Report the apic_id in debug messages for each AP
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
---
Makefile| 3 +-
src/config.h| 1 +
src/fw/smp.c| 102
Il 31/05/2014 03:20, Kevin O'Connor ha scritto:
Change the multi-processor init code to trampoline into 32bit mode on
each of the additional processors. Implement an atomic lock so that
each processor performs its initialization serially.
I don't see much benefit in this change, in fact the
The next patch will add shared code between the initial handler for
SMBASE relocation and the actual SMI handler. Combine the code of
the two handlers for simplicity.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
src/fw/smm.c | 27 +++
1 file changed, 11
SMI generation requires two bits to be set in PIIX4, one for APMC
interrupts specifically and a general one.
For Q35 it is the same, plus it is a good thing to lock SMIs after
enabling them.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
src/fw/dev-piix.h | 2 ++
src/fw/dev-q35.h | 3
Move all definitions for PIIX registers to a single header file,
like there is one already for Q35, and make the naming more
consistent.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
src/fw/acpi.c | 18 ++
src/fw/dev-piix.h | 27 +++
src/fw
Il 28/05/2014 18:04, Kevin O'Connor ha scritto:
On Fri, May 16, 2014 at 09:29:59AM +0200, Paolo Bonzini wrote:
Il 15/05/2014 20:57, Kevin O'Connor ha scritto:
On Thu, May 15, 2014 at 06:36:08PM +0200, Paolo Bonzini wrote:
I think this is more easily visible on top of these patches more than
Il 15/05/2014 20:57, Kevin O'Connor ha scritto:
On Thu, May 15, 2014 at 06:36:08PM +0200, Paolo Bonzini wrote:
I think this is more easily visible on top of these patches more than the
other way round, but I'm biased of course...
I was referring to your patch 5, which adds a bunch
Hi,
these patches provide a small set of improvements and cleanups for the
current SMM code, making it more consistent with the chipset's datasheets.
QEMU does not yet implement most of the new registers used here, but it
might soon...
Paolo Bonzini (5):
piix: add and use dev-piix.h
smm
Move all definitions for PIIX registers to a single header file,
like there is one already for Q35, and make the naming more
consistent.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
src/fw/acpi.c | 18 ++
src/fw/dev-piix.h | 27 +++
src/fw
This is handled already in QEMU, no need to do it in SMM.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
src/fw/smm.c | 25 -
1 file changed, 25 deletions(-)
diff --git a/src/fw/smm.c b/src/fw/smm.c
index 4176e0c..07f9234 100644
--- a/src/fw/smm.c
+++ b/src/fw
-off-by: Paolo Bonzini pbonz...@redhat.com
---
src/fw/dev-piix.h | 3 +++
src/fw/dev-q35.h | 3 +++
src/fw/smm.c | 26 ++
3 files changed, 32 insertions(+)
diff --git a/src/fw/dev-piix.h b/src/fw/dev-piix.h
index c389f17..5df0a89 100644
--- a/src/fw/dev-piix.h
+++ b
The next patch will add shared code between the initial handler for
SMBASE relocation and the actual SMI handler. Combine the code of
the two handlers for simplicity.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
src/fw/smm.c | 27 +++
1 file changed, 11
Il 13/05/2014 17:00, Kevin O'Connor ha scritto:
On Tue, May 13, 2014 at 02:58:29PM +0200, Gerd Hoffmann wrote:
Hi,
Digged out an old patch from the mailing list, to make smm use
acpi_pm1a_cnt. This allows to make the acpi pmbase a variable
and figure where to place the registers at runtime.
Il 15/05/2014 14:56, Don Koch ha scritto:
On Thu, 15 May 2014 13:22:27 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
This is handled already in QEMU, no need to do it in SMM.
Is it needed by coreboot?
CoreBoot does not run this code at all.
Paolo
-d
Signed-off-by: Paolo Bonzini pbonz
Il 15/05/2014 14:56, Don Koch ha scritto:
On Thu, 15 May 2014 13:22:27 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
This is handled already in QEMU, no need to do it in SMM.
Is it needed by coreboot?
This code doesn't run on coreboot.
Paolo
-d
Signed-off-by: Paolo Bonzini pbonz
Il 15/05/2014 17:05, Kevin O'Connor ha scritto:
On Thu, May 15, 2014 at 01:22:25PM +0200, Paolo Bonzini wrote:
Hi,
these patches provide a small set of improvements and cleanups for the
current SMM code, making it more consistent with the chipset's datasheets.
QEMU does not yet implement most
Il 06/02/2014 14:38, Gabriel L. Somlo ha scritto:
But anyhow, right now QEMU seems to be making relatively minor tweaks
to something that's firmly at home in SeaBIOS, which is why I sent my
patches to the latter...
Yeah, that's correct. There's really no particular hook in QEMU to do this.
(ioaddr);
goto fail;
+}
return;
fail:
free(vq);
}
Thanks Laszlo!
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Paolo
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Il 18/12/2013 16:59, Gal Hammer ha scritto:
Note this is not the APIC base address, that one is 80h on the ISA
bridge (function 0). You're changing the behavior for 80h on the power
management function, which is function 3. The register is PMBA—POWER
MANAGEMENT BASE ADDRESS and it is indeed
Il 18/12/2013 23:10, Laszlo Ersek ha scritto:
So, if PEI must do something after S3 resume that is independent of any
DXE drivers, it can simply do it. The boot script is only necessary when
the S3 resume PEI actions (in step 6) need to depend on earlier actions
during DXE (step 3).
In
Il 27/11/2013 16:53, Igor Mammedov ha scritto:
Patch looks good,
Please add patch to update hw/i386/ssdt-proc.hex.generated for hosts without
iasl
for completness
Also please rename PXM to CPXM or CPPX for consistency.
Paolo
---
hw/i386/acpi-build.c |5 +
Il 21/11/2013 23:02, Gabriel L. Somlo ha scritto:
On Thu, Nov 21, 2013 at 07:14:27PM +0100, Paolo Bonzini wrote:
Can you remind us about your DSDT modifications? It should be possible
to patch the HPET and applesmc bits appropriately from QEMU (or to move
them from the DSDT to an SSDT
Il 11/11/2013 23:18, Gabriel L. Somlo ha scritto:
OK, so it turns out I now have to patch the .dsl files under the qemu
tree (hw/i386/acpi-dsdt-[hpet|isa].dsl), and the -acpitable file=...
qemu command line option is deprecated...
I guess I'm allright now, so nevermind... :)
Can you remind
Il 15/09/2013 07:08, Kevin O'Connor ha scritto:
Signed-off-by: Kevin O'Connor ke...@koconnor.net
---
src/stacks.h | 34 ++
1 file changed, 34 insertions(+)
create mode 100644 src/stacks.h
diff --git a/src/stacks.h b/src/stacks.h
new file mode 100644
Il 08/08/2013 12:20, Mario ha scritto:
root@mario-ThinkCentre-:/home/marietto/Scrivania# git clone
git://git.seabios.org/seabios.git
Cloning into 'seabios'...
remote: Counting objects: 9725, done.
remote: Compressing objects: 100% (4284/4284), done.
remote: Total 9725 (delta 7736),
Il 09/08/2013 16:33, Mario ha scritto:
hello to everyone. The Paolo's solution worked for me,but it's not
good for the goal that I want to achieve. I would like to virtualize
Mac OS X with KVM on the mac mini but I see that this solution has
created a situation worse than than before. Check
On 08/05/2013 09:19 PM, Eric Blake wrote:
On 08/05/2013 01:04 PM, Paolo Bonzini wrote:
Libvirt has no problem enabling -device pvpanic for all guests where
on_crash is set to a non-default value, since the use of on_crash is
a sufficient hint that the user expects the guest to be able
ATM it looks like we should test
Windows 2000 ||
Windows 2001 ||
Windows 2001 SP1 ||
Windows 2001.1 SP1
Including this may be too strict, what about 98/ME?
Isn't this past EOL?
So what? People try to use it with QEMU, and it's fair to assume
it's
for example: in Windows(let's say XP) the Device manager will open a
new device wizard and the device will appear as an unrecognized
device. On a cluster with hundreds of such VMs, If that cluster has
a health monitoring service it may show all the VMs in a not healthy
state.
Is this
That's just pushing the problem elsewhere. How management suppose to know
if guest support pvpanic device?
The problem isn't new and management already does that when figuring
whenever the guest should get ide/ahci/virtio-blk/virtio-scsi storage,
ac97 or intel-hda sound,
This patch is a workaround to not show pvpanic in UI to avoid the
problem in Windows.
It's not a workaround, it is a proper bugfix.
What versions of Windows did you test it on? Did it hide the New
Hardware wizard properly (I think it appears only on XP/2003)?
Windows XP. I
That's just pushing the problem elsewhere. How management suppose to
know
if guest support pvpanic device?
The problem isn't new and management already does that when figuring
whenever the guest should get ide/ahci/virtio-blk/virtio-scsi storage,
ac97 or intel-hda sound,
On 07/31/2013 08:14 AM, Igor Mammedov wrote:
Windows operating systems return 0x if the argument to the
_OSI method specifies an earlier version of Windows. For example,
Windows 7 returns 0x for both “Windows 2009” (Windows 7) and
“Windows 2006” (Windows Vista®).
This would
On 08/05/2013 06:18 PM, Michael S. Tsirkin wrote:
Depending on the management, management could just be the user.
Most of the time the user simply says to use virtio in the XML.
If it had to be specified manually every time, pvpanic would be
just another knob that nobody uses.
Management
Libvirt has no problem enabling -device pvpanic for all guests where
on_crash is set to a non-default value, since the use of on_crash is
a sufficient hint that the user expects the guest to be able to notify
of a crash in the first place. But I definitely agree that it is more
conservative
From my quick research, it looks like Windows 2006 || Windows
2006.1 || Linux would work, but I have not tested it.
Paolo
This doesn't work in that it matches linux.
Note that the above was meant to be a condition for when to _show_
the PCI hole, i.e. negated compared to your
Il 24/07/2013 17:09, Andreas Färber ha scritto:
Hi,
Am 24.07.2013 17:04, schrieb Gerd Hoffmann:
/me suggests to check out qmp_qom_get() in qmp.c. Some qom aequivalent
for qdev_find_recursive would be handy, dunno whenever such a thing
exists already, Andreas?
Not sure what's needed here?
+ SLP_BUTTON + RTC_S4 + USE_PLATFORM_CLOCK */
+fadt-flags = cpu_to_le32((1 0) | (1 2) | (1 5) | (1 7) |
+ (1 15));
}
static const struct pci_device_id fadt_init_tbl[] = {
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Il 11/06/2013 03:35, Michael S. Tsirkin ha scritto:
Two points
1. You never explained what you mean by un-hardware like.
Currently bios is in a ROM device, and it has a
template for ACPI tables together with it.
This simply moves the tables to a separate ROM
device (FW CFG),
Il 02/06/2013 17:05, Gleb Natapov ha scritto:
Anthony requested that patches be made that generate the ACPI tables
in QEMU for the upcoming hotplug work, so that they could be evaluated
to see if they truly do need to live in QEMU or if the code could live
in the firmware. There were no
Il 31/05/2013 19:06, Anthony Liguori ha scritto:
David Woodhouse dw...@infradead.org writes:
On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote:
It's even more fundamental. OVMF as a whole (at least in it's usable
form) is not Open Source.
The FAT module is required to make EDK2
. then it will not effect other devices
don't have get_fw_dev_path() implementation.
v3: implement default get_fw_dev_path() in BusClass
Thanks!
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
---
hw/core/qdev.c | 10 +-
hw/virtio/virtio-bus.c | 6 ++
2 files changed, 15 insertions(+), 1
Il 28/05/2013 11:35, Amos Kong ha scritto:
On Tue, May 28, 2013 at 10:06:51AM +0200, Paolo Bonzini wrote:
Il 28/05/2013 09:40, Amos Kong ha scritto:
bootindex parameter of scsi device doesn't work, it causes
by wrong pattern in seabios.
qemu passes the following firmware dev_path to seabios
type.
This patch fixes the pattern to match both original pc-i440fx q35
Signed-off-by: Amos Kong ak...@redhat.com
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
---
src/boot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/boot.c b/src/boot.c
index cd9d784
Il 15/05/2013 18:25, Laszlo Ersek ha scritto:
(Not sure why the CC list has grown this huge, but I'm adding Drew for
good mesaure.)
On 05/15/13 09:27, Hu Tao wrote:
On Wed, May 15, 2013 at 09:21:54AM +0200, Laszlo Ersek wrote:
On 04/05/13 09:17, Hu Tao wrote:
+Method(RDPT, 0,
Il 05/04/2013 09:17, Hu Tao ha scritto:
pvpanic device is used to notify host(qemu) when guest panic happens.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Hu Tao hu...@cn.fujitsu.com
---
No change from v16. qemu patches at:
http://lists.nongnu.org/archive/html/qemu
Il 09/04/2013 06:33, Nicholas A. Bellinger ha scritto:
Nicholas, where is the latest v3 code. Can you push it to your tree.
Sure. Just pushed to:
http://git.kernel.org/cgit/virt/kvm/nab/qemu-kvm.git/log/?h=vhost-scsi-for-1.4
and should be appearing momentarily.
I'm going to test my
Considering the following when the same seabios code snippet:
pci_config_writeb(0x31): bdf: 0x pam: 0x005b
is executed to mark an pc.ram area 0xc as readonly:
Entering vhost_begin
Entering vhost_region_del section: 0x7fd037a4bb60 offset_within_region:
0xc
Il 30/03/2013 14:20, Kevin O'Connor ha scritto:
On Fri, Mar 29, 2013 at 02:49:12PM +0100, Paolo Bonzini wrote:
Il 29/03/2013 14:33, Kevin O'Connor ha scritto:
On Fri, Mar 29, 2013 at 04:18:44PM +0800, Hu Tao wrote:
pvpanic device is used to notify host(qemu) when guest panic happens.
Thanks
Il 29/03/2013 03:53, Nicholas A. Bellinger ha scritto:
On Thu, 2013-03-28 at 06:13 -0400, Paolo Bonzini wrote:
I think it's the right thing to do, but maybe not the right place
to do this, need to reset after all IO is done, before
ring memory is write protected.
Our emails are crossing each
Il 29/03/2013 09:18, Hu Tao ha scritto:
pvpanic device is used to notify host(qemu) when guest panic happens.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Hu Tao hu...@cn.fujitsu.com
---
src/acpi.c| 3 +++
src/ssdt-misc.dsl | 46
Il 29/03/2013 14:33, Kevin O'Connor ha scritto:
On Fri, Mar 29, 2013 at 04:18:44PM +0800, Hu Tao wrote:
pvpanic device is used to notify host(qemu) when guest panic happens.
Thanks. However, we're planning a move of ACPI tables from SeaBIOS to
QEMU. I think this should wait until after the
Il 26/03/2013 15:14, Corey Bryant ha scritto:
This patch provides ACPI support for the TPM device. It probes for the TPM
device and only if a TPM device is found then the TPM's SSDT and TCPA table
are created. This patch also connects them to the RSDT.
Since the logging area in the TCPA
Il 28/03/2013 10:04, Michael S. Tsirkin ha scritto:
Got ranges_overlap for vq: 0 ring_phys: 0 ring_size: 1028
Checking vq: 1 ring_phys: 0 ring_size: 1028 .
Got ranges_overlap for vq: 1 ring_phys: 0 ring_size: 1028
Checking vq: 2 ring_phys: ed000 ring_size: 5124 .
Calling l: 5124 for
I think it's the right thing to do, but maybe not the right place
to do this, need to reset after all IO is done, before
ring memory is write protected.
Our emails are crossing each other unfortunately, but I want to
reinforce this: ring memory is not write protected. Remember that
SeaBIOS
Il 26/03/2013 02:59, Hu Tao ha scritto:
Why doesn't it work with q35?
ACPI_EXTRACT_NAME_WORD_CONST dsdt_isa_pest generates two dsdt_isa_pest,
one in out/acpi-dsdt.hex the other in out/q35-acpi-dsdt.hex. We should
use the one in q35-acpi-dsdt.hex to patch DSDT for q35. But including
Il 26/03/2013 08:24, Hu Tao ha scritto:
ACPI_EXTRACT_NAME_WORD_CONST dsdt_isa_pest generates two dsdt_isa_pest,
one in out/acpi-dsdt.hex the other in out/q35-acpi-dsdt.hex. We should
use the one in q35-acpi-dsdt.hex to patch DSDT for q35. But including
q35-acpi-dsdt.hex, along with
Il 22/03/2013 17:09, Laszlo Ersek ha scritto:
I'm confused. What are the requirements?
(1) should unpatched qemu work with patched seabios?
Yes.
(2) should patched qemu work with unpatched seabios?
No.
Considering patched qemu + patched seabios,
(3) should qemu dynamically control table
Il 22/03/2013 00:22, Kevin O'Connor ha scritto:
This also needs
to be resolved for SSDT tables, which can have zero, one, or more
instances.
Same argument as for the MADT.
The issue with the SSDT is that there can be many of them. QEMU may
wish to pass in 2 or more. If QEMU does
Il 21/03/2013 14:12, Michael S. Tsirkin ha scritto:
On Thu, Mar 21, 2013 at 01:04:35PM +, David Woodhouse wrote:
On Thu, 2013-03-21 at 13:56 +0100, Laszlo Ersek wrote:
- for an earlier qemu, the option must be set,
- for a later qemu the option must be clear
(no -acpitable switch must
Il 21/03/2013 16:54, Laszlo Ersek ha scritto:
+Dynamically build the ACPI MADT (APIC) table in SeaBIOS, based on
+individual values exported by QEMU and online status of VCPUs.
+Required for QEMU 1.4 and older.
+This option can (and should) be
101 - 200 of 333 matches
Mail list logo
