On Sun, Nov 22, 2009 at 09:41:26PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Sun, Nov 22, 2009 at 06:39:16PM +0100, Sebastian Herbszt wrote:
> >>Gleb Natapov wrote:
> >>>On Sun, Nov 22, 2009 at 05:51:41PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >Microsoft S
On Mon, Nov 23, 2009 at 12:57:14AM +0100, Carl-Daniel Hailfinger wrote:
> On 22.11.2009 18:39, Sebastian Herbszt wrote:
> > Gleb Natapov wrote:
> >> On Sun, Nov 22, 2009 at 05:51:41PM +0100, Sebastian Herbszt wrote:
> >>> Is the requirement for "Targeted Content Delivery" specified
> >>> somewhere
Sebastian Herbszt wrote:
H. Peter Anvin wrote:
Add generic support for debugging consoles (simple I/O ports which
when written to cause debugging output to be written to a target.)
The current implementation matches Bochs' port 0xe9, allowing the same
debugging code to be used for both Bochs and
Paolo Bonzini wrote:
I don't see how this fixes anything. If you used feature bits, how do
you migrate from a version that has a feature bit that an older version
doesn't know about? Do you just ignore it?
I'd go with chunk instead of feature bits, specifying them like in the
PNG specificati
On 22.11.2009 18:39, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
>> On Sun, Nov 22, 2009 at 05:51:41PM +0100, Sebastian Herbszt wrote:
>>> Is the requirement for "Targeted Content Delivery" specified
>>> somewhere with something more
>>> clear than "SMBIOS data is useful in identifying the compu
Kevin O'Connor wrote:
On Sun, Nov 22, 2009 at 05:38:09PM +0200, Gleb Natapov wrote:
On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
>// Write protect bios memory.
>make_bios_readonly();
Hmmm. How is tpr patching works then? It relies on ability of a guest to
write into
Kevin O'Connor wrote:
On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
> Bad things could happen if someone modifies the BIOS because it's unprotected
> (e.g. VM crash).
I'm not sure why modification of the BIOS would cause a VM crash. If
this is true, then a malicious guest
Gleb Natapov wrote:
On Sun, Nov 22, 2009 at 06:39:16PM +0100, Sebastian Herbszt wrote:
Gleb Natapov wrote:
>On Sun, Nov 22, 2009 at 05:51:41PM +0100, Sebastian Herbszt wrote:
>>Gleb Natapov wrote:
>>>Microsoft SVVP (Server Virtualization Validation Program) expects
>>>arbitrary SMBIOS field to h
I don't see how this fixes anything. If you used feature bits, how do
you migrate from a version that has a feature bit that an older version
doesn't know about? Do you just ignore it?
I'd go with chunk instead of feature bits, specifying them like in the
PNG specification:
Each chunk
Gleb Natapov wrote:
On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
Bad things could happen if someone modifies the BIOS because it's unprotected
(e.g. VM crash).
BIOS is reloaded during VM reset.
The BIOS is not reloaded - tested with "reboot" on Linux and system_reset i
On 11/22/2009 7:39 PM, Sebastian Herbszt wrote:
>/* Type 16 -- Physical Memory Array */
>@@ -239,7 +240,7 @@ smbios_init_type_16(void *start, u32
memory_size_mb, int nr_mem_devs)
>
>p->location = 0x01; /* other */
>p->use = 0x03; /* system memory */
>-p->error_correction = 0x01;
On Sun, Nov 22, 2009 at 06:39:16PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Sun, Nov 22, 2009 at 05:51:41PM +0100, Sebastian Herbszt wrote:
> >>Gleb Natapov wrote:
> >>>Microsoft SVVP (Server Virtualization Validation Program) expects
> >>>arbitrary SMBIOS field to have certain v
Luiz Capitulino wrote:
This commit adds a flag called 'control' to the '-monitor'
command-line option. This flag enables control mode.
The syntax is:
qemu [...] -monitor control,
Where is a chardev (excluding 'vc', for obvious reasons).
For example:
$ qemu [...] -monitor control,tcp:localho
Gleb Natapov wrote:
On Sun, Nov 22, 2009 at 05:51:41PM +0100, Sebastian Herbszt wrote:
Gleb Natapov wrote:
>Microsoft SVVP (Server Virtualization Validation Program) expects
>arbitrary SMBIOS field to have certain values otherwise it fails.
>We all want to make Microsoft happy don't we? So lets
On Sun, Nov 22, 2009 at 05:38:09PM +0200, Gleb Natapov wrote:
> On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
> >// Write protect bios memory.
> >make_bios_readonly();
> Hmmm. How is tpr patching works then? It relies on ability of a guest to
> write into BIOS memory re
On Sun, Nov 22, 2009 at 05:51:41PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >Microsoft SVVP (Server Virtualization Validation Program) expects
> >arbitrary SMBIOS field to have certain values otherwise it fails.
> >We all want to make Microsoft happy don't we? So lets put values MS
>
On Sun, Nov 22, 2009 at 06:08:15PM +0100, Sebastian Herbszt wrote:
> Etherboot 5.4.3 rom doesn't work due to missing BIOS32 support:
> pci_init: no BIOS32 detected
>
> Works with Bochs bios.
Thanks Sebastian.
The 32bit pcibios and int1589 are the only two features I know of that
Bochs bios has th
H. Peter Anvin wrote:
Add generic support for debugging consoles (simple I/O ports which
when written to cause debugging output to be written to a target.)
The current implementation matches Bochs' port 0xe9, allowing the same
debugging code to be used for both Bochs and Qemu.
Your implementati
Etherboot 5.4.3 rom doesn't work due to missing BIOS32 support:
pci_init: no BIOS32 detected
Works with Bochs bios.
- Sebastian
On Sun, Nov 22, 2009 at 04:08:53PM +0200, Gleb Natapov wrote:
> Microsoft SVVP (Server Virtualization Validation Program) expects
> arbitrary SMBIOS field to have certain values otherwise it fails.
> We all want to make Microsoft happy don't we? So lets put values MS
> expects in there.
[...]
> -
v0.11.0-rc0-1677:
use -cpu pentium and check SMBIOS tables. DMI type 4 entry is missing.
Works with Bochs bios.
- Sebastian
Gleb Natapov wrote:
Microsoft SVVP (Server Virtualization Validation Program) expects
arbitrary SMBIOS field to have certain values otherwise it fails.
We all want to make Microsoft happy don't we? So lets put values MS
expects in there.
Values modified by the patch:
Type 0:
Bit 2 of byte 2 mus
Markus Armbruster wrote:
I'm thinking and talking primarily about the protocol, and that probably
makes me too terse on implementation.
I didn't mean to suggest that for adding the data part we should add new
arguments providing the data. That would be dumb indeed.
Instead, I'd like to start w
On Sun, Nov 22, 2009 at 09:40:52AM -0600, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> Here's the list of patches on my pci fixes tree:
>> git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git pci
>>
>> Here are the pci fixes I know of that haven't been applied already.
>> They mostly
Luiz Capitulino wrote:
{ "execute": "info", "arguments": { "item": "balloon" } }
{"return": 512}
{ "execute": "info", "arguments": { "item": "network" } }
{"return": [{"devices": [{"name": "user.0", "info": "net=10.0.2.0, restricted=n"}, {"name": "e1000.0",
"info": "model=e1000,macaddr=52:54:00
Dor Laor wrote:
In the last couple of days we discovered some issues regarding stable
ABI and the robustness of the live migration protocol. Let's just jump
right into it, ordered by complexity:
1. Control *every* feature exposed to the guest by qemu cmdline:
While thinking on cross versio
Michael S. Tsirkin wrote:
Here's the list of patches on my pci fixes tree:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git pci
Here are the pci fixes I know of that haven't been applied already.
They mostly fix up minor nits. All, any more comments on any of them?
If yes, please repl
On Sun, Nov 22, 2009 at 05:10:53PM +0200, Gleb Natapov wrote:
> On Sun, Nov 22, 2009 at 04:07:56PM +0100, Sebastian Herbszt wrote:
> > Gleb Natapov wrote:
> > >May be make qemu to map it writable if isapc is specified.
> >
> > I don't think keeping the segment writable after POST is a good idea.
>
On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Sun, Nov 22, 2009 at 04:07:56PM +0100, Sebastian Herbszt wrote:
> >>Gleb Natapov wrote:
> >>>May be make qemu to map it writable if isapc is specified.
> >>
> >>I don't think keeping the segment writable
Gleb Natapov wrote:
On Sun, Nov 22, 2009 at 04:07:56PM +0100, Sebastian Herbszt wrote:
Gleb Natapov wrote:
>May be make qemu to map it writable if isapc is specified.
I don't think keeping the segment writable after POST is a good idea.
Isn't it writable now after POST with pcipc? Why this is
Here's the list of patches on my pci fixes tree:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git pci
Here are the pci fixes I know of that haven't been applied already.
They mostly fix up minor nits. All, any more comments on any of them?
If yes, please reply on the original patch, not
On Sun, Nov 22, 2009 at 04:07:56PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Fri, Nov 20, 2009 at 05:51:13PM -0500, Kevin O'Connor wrote:
> >>On Thu, Nov 19, 2009 at 10:30:20PM +0100, Sebastian Herbszt wrote:
> >>> i386-softmmu/qemu -M isapc -bios pc-bios/bios.bin
> >>
> >>Thanks
Gleb Natapov wrote:
On Fri, Nov 20, 2009 at 05:51:13PM -0500, Kevin O'Connor wrote:
On Thu, Nov 19, 2009 at 10:30:20PM +0100, Sebastian Herbszt wrote:
> i386-softmmu/qemu -M isapc -bios pc-bios/bios.bin
Thanks for reporting this.
After compiling seabios with CONFIG_DEBUG_SERIAL set in src/conf
In the last couple of days we discovered some issues regarding stable
ABI and the robustness of the live migration protocol. Let's just jump
right into it, ordered by complexity:
1. Control *every* feature exposed to the guest by qemu cmdline:
While thinking on cross version migration, and
On Sun, 22 Nov 2009 11:41:02 +0200
Avi Kivity wrote:
> On 11/19/2009 06:47 PM, Luiz Capitulino wrote:
> >
> >> Can you post a capture of a few monitor commands through the new protocol?
> >>
> > Here goes, it's a telnet session:
> >
>
> Looks really good, some comments below.
>
> >
On Sun, Nov 22, 2009 at 10:07 PM, Stefan Weil wrote:
> All files config-devices.mak are copies from files in
> directory default-configs.
>
> Creating these copies during configuration ignores these
> dependencies and may result in unresolved externals
> from incremental builds when files in defau
Microsoft SVVP (Server Virtualization Validation Program) expects
arbitrary SMBIOS field to have certain values otherwise it fails.
We all want to make Microsoft happy don't we? So lets put values MS
expects in there.
Values modified by the patch:
Type 0:
Bit 2 of byte 2 must be 1
Type 1:
Ma
All files config-devices.mak are copies from files in
directory default-configs.
Creating these copies during configuration ignores these
dependencies and may result in unresolved externals
from incremental builds when files in default-configs
are modified.
By adding a dependency rule to Makefile
[WIN32] Enable -k option on Windows too
There is no reason to have it disabled on this platform.
Signed-off-by: Hervé Poussineau
---
vl.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/vl.c b/vl.c
index c3f3c8f..ee43808 100644
--- a/vl.c
+++ b/vl.c
@@ -5042,11 +5042,9 @
On Fri, Nov 20, 2009 at 05:51:13PM -0500, Kevin O'Connor wrote:
> On Thu, Nov 19, 2009 at 10:30:20PM +0100, Sebastian Herbszt wrote:
> > i386-softmmu/qemu -M isapc -bios pc-bios/bios.bin
>
> Thanks for reporting this.
>
> After compiling seabios with CONFIG_DEBUG_SERIAL set in src/config.h
> and
On 11/19/2009 06:47 PM, Luiz Capitulino wrote:
Can you post a capture of a few monitor commands through the new protocol?
Here goes, it's a telnet session:
Looks really good, some comments below.
"""
{"QMP": {"capabilities": []}}
{ "execute": "info", "arguments": { "item": "ba
On 11/21/2009 12:36 AM, Kevin O'Connor wrote:
It looks like I spoke too soon. It appears the SeaBIOS init can leave
the ATA controller in an interrupts disabled state. This appears to
confuse Vista. So, this is a SeaBIOS bug - I'll implement a fix.
I've committed a fix to SeaBIOS - co
42 matches
Mail list logo
