On 01/06/16 14:39, Igor Mammedov wrote:
> On Tue, 5 Jan 2016 18:22:33 +0100
> Laszlo Ersek <ler...@redhat.com> wrote:
>
>> On 01/05/16 18:08, Igor Mammedov wrote:
>>> On Mon, 4 Jan 2016 21:17:31 +0100
>>> Laszlo Ersek <ler...@redhat.com> wrote:
&
On 01/05/16 18:08, Igor Mammedov wrote:
> On Mon, 4 Jan 2016 21:17:31 +0100
> Laszlo Ersek <ler...@redhat.com> wrote:
>
>> Michael CC'd me on the grandparent of the email below. I'll try to add
>> my thoughts in a single go, with regard to OVMF.
>>
>> On 1
On 01/05/16 17:43, Michael S. Tsirkin wrote:
> On Tue, Jan 05, 2016 at 05:30:25PM +0100, Igor Mammedov wrote:
bios-linker-loader is a great interface for initializing some
guest owned data and linking it together but I think it adds
unnecessary complexity and is misused if it's used
Michael CC'd me on the grandparent of the email below. I'll try to add
my thoughts in a single go, with regard to OVMF.
On 12/30/15 20:52, Michael S. Tsirkin wrote:
> On Wed, Dec 30, 2015 at 04:55:54PM +0100, Igor Mammedov wrote:
>> On Mon, 28 Dec 2015 14:50:15 +0200
>> "Michael S. Tsirkin"
On 11/02/15 10:32, Paolo Bonzini wrote:
>
>
> On 31/10/2015 20:50, Laszlo Ersek wrote:
>> Tested-by: Laszlo Ersek <ler...@redhat.com>
>
> Thanks Laszlo, I applied patches 1 and 2 (since your "part 2" never was :)).
>
> Paolo
>
Thanks.
Since y
On 11/03/15 15:04, Paolo Bonzini wrote:
>
>
> On 03/11/2015 15:02, Laszlo Ersek wrote:
>> On 11/03/15 14:46, Paolo Bonzini wrote:
>>>
>>>
>>> On 03/11/2015 14:40, Laszlo Ersek wrote:
>>>> On 11/03/15 14:29, Paolo Bonzini wrote:
>>>
On 11/03/15 19:34, Laszlo Ersek wrote:
> Commit b18d5431acc7 ("KVM: x86: fix CR0.CD virtualization") was
> technically correct, but it broke OVMF guests by slowing down various
> parts of the firmware.
>
> Commit fb279950ba02 ("KVM: vmx: obey KVM_QUIRK_CD_NW_CLEARED&
it b18d5431acc7.
Cc: Paolo Bonzini <pbonz...@redhat.com>
Cc: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Janusz Mocek <janusz...@gmail.com>
Cc: Alex Williamson <alex.william...@redhat.com>
Cc: Xiao Guangrong <guangrong.x...@linux.intel.com>
Signed-off-by: Laszlo Ers
On 11/03/15 14:46, Paolo Bonzini wrote:
>
>
> On 03/11/2015 14:40, Laszlo Ersek wrote:
>> On 11/03/15 14:29, Paolo Bonzini wrote:
>>> The SDM says that exiting system management mode from 64-bit mode
>>> is invalid, but that would be too good to be true. B
all the way from 64-bit
> mode to real mode only requires clearing CS.L and CR4.PCIDE.
>
> Cc: sta...@vger.kernel.org
> Fixes: 660a5d517aaab9187f93854425c4c63f4a09195c
> Cc: Laszlo Ersek <ler...@redhat.com>
> Cc: Radim Krčmář <rkrc...@redhat.com>
> Sign
ode
>
> arch/x86/include/asm/kvm_emulate.h | 10 +
> arch/x86/kvm/emulate.c | 44
> +-
> arch/x86/kvm/x86.c | 10 +
> 3 files changed, 30 insertions(+), 34 deletions(-)
>
Tested-by: Laszlo E
On 10/30/15 16:40, Radim Krčmář wrote:
> 2015-10-26 17:32+0100, Paolo Bonzini:
>> On 26/10/2015 16:43, Laszlo Ersek wrote:
>>>> The code would be cleaner if we had a different approach, but this works
>>>> too and is safer for stable. In case you prefer to le
On 10/26/15 16:37, Radim Krčmář wrote:
> 2015-10-23 23:43+0200, Laszlo Ersek:
>> Commit b10d92a54dac ("KVM: x86: fix RSM into 64-bit protected mode")
>> reordered the rsm_load_seg_64() and rsm_enter_protected_mode() calls,
>> relative to each other. The argument th
ocal array, not the
guest's SMRAM.
Fixes: b10d92a54dac25a6152f1aa1ffc95c12908035ce
Cc: Paolo Bonzini <pbonz...@redhat.com>
Cc: Radim Krčmář <rkrc...@redhat.com>
Cc: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Michael Kinney <michael.d.kin...@intel.com>
Cc: sta...@vger.kernel.or
Hi,
On 10/20/15 19:27, Janusz wrote:
> W dniu 15.10.2015 o 20:46, Laszlo Ersek pisze:
>> On 10/15/15 18:53, Kinney, Michael D wrote:
>>> Laszlo,
>>>
>>> There is already a PCD for this timeout that is used by CpuMpPei.
>>>
>>> gUefi
On 10/16/15 05:05, Xiao Guangrong wrote:
>
>
> On 10/16/2015 12:18 AM, Laszlo Ersek wrote:
>> CC'ing Jordan and Chen Fan.
>>
>> On 10/15/15 09:10, Xiao Guangrong wrote:
>>>
>>>
>>> On 10/15/2015 02:58 PM, Janusz wrote:
>>>> W dniu
CC'ing Jordan and Chen Fan.
On 10/15/15 09:10, Xiao Guangrong wrote:
>
>
> On 10/15/2015 02:58 PM, Janusz wrote:
>> W dniu 15.10.2015 o 08:41, Xiao Guangrong pisze:
>>>
>>>
>>> On 10/15/2015 02:19 PM, Janusz wrote:
W dniu 15.10.2015 o 06:19, Xiao Guangrong pisze:
>
>
>
>
it, and an
explanation why 100*1000 is no longer sufficient on KVM :)
Thanks!
Laszlo
>
> Mike
>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Laszlo Ersek
>> Sent: Thursday, October 15, 2015 9:19
On 10/14/15 10:32, Xiao Guangrong wrote:
>
>
> On 10/14/2015 04:24 PM, Xiao Guangrong wrote:
>>
>>
>> On 10/14/2015 03:37 PM, Janusz wrote:
>>> I was able to run my virtual machine with this, but had very high cpu
>>> usage when something happen in it like booting system. once, my virtual
>>>
On 09/18/15 11:37, Janusz wrote:
> Hello,
>
> I am writting about this patch that was posted by Xiao:
> http://www.spinics.net/lists/kvm/msg119044.html and this:
> http://www.spinics.net/lists/kvm/msg119045.html
> I've tested both kernel 4.2 and 4.3 and problem still exists when I use
> OVMF -
On 08/07/15 12:38, Paolo Bonzini wrote:
On 07/08/2015 01:02, Laszlo Ersek wrote:
The trace covers the full lifetime of the guest (I started tracing
before launching the guest, and I passed -no-reboot to qemu, so when the
guest crashed, QEMU exited.)
This was on 3.10.0-299.el7.x86_64.
I
On 08/07/15 00:38, Laszlo Ersek wrote:
On 08/06/15 16:55, Paolo Bonzini wrote:
On 06/08/2015 16:31, Laszlo Ersek wrote:
kvm_cpuid:func 8001 rax 6e8 rbx 0 rcx 0 rdx 10
kvm_enter_smm:vcpu 0: leaving SMM, smbase 0x7ffc
kvm_entry:vcpu 0
kvm_exit
On 08/06/15 16:55, Paolo Bonzini wrote:
On 06/08/2015 16:31, Laszlo Ersek wrote:
kvm_cpuid:func 8001 rax 6e8 rbx 0 rcx 0 rdx 10
kvm_enter_smm:vcpu 0: leaving SMM, smbase 0x7ffc
kvm_entry:vcpu 0
kvm_exit: reason TRIPLE_FAULT rip
Separate followup message with the symptoms I managed to gather about
the failure on KVM.
On 08/06/15 15:42, Laszlo Ersek wrote:
Hi Star,
On 08/06/15 11:44, Zeng, Star wrote:
Hi Laszlo,
Could you help take a try with the attached patch on your VM before I
send it for formal review?
I got
On 07/15/15 00:37, Jordan Justen wrote:
On 2015-07-14 14:29:11, Laszlo Ersek wrote:
On 07/14/15 23:15, Paolo Bonzini wrote:
The long delay that Alex reported (for the case when all guest memory
was set to UC up-front) is due to the fact that the SEC phase of OVMF
decompresses an approximately
On 07/15/15 21:30, Xiao Guangrong wrote:
Hi,
I have posted the pachset to make OVMF happy and have CCed you guys,
could you please check it if it works for you?
Sorry, I can't check it; I don't have an environment that exposes the
issue in the first place. Perhaps Alex can check it, or
Cross-posting to edk2-devel.
Original sub-thread starts here:
http://thread.gmane.org/gmane.linux.kernel/1952205/focus=1994315
On 07/13/15 17:15, Xiao Guangrong wrote:
On 07/13/2015 11:13 PM, Paolo Bonzini wrote:
On 13/07/2015 16:45, Xiao Guangrong wrote:
+/* MTRR is completely
On 07/14/15 23:15, Paolo Bonzini wrote:
The long delay that Alex reported (for the case when all guest memory
was set to UC up-front) is due to the fact that the SEC phase of OVMF
decompresses an approximately 1712 KB sized, LZMA-compressed blob, to
approx. 896 KB worth of PEI drivers and 8192
On 07/10/15 16:13, Paolo Bonzini wrote:
On 09/07/2015 20:57, Laszlo Ersek wrote:
Without EPT, you don't
hit the processor limitation with your setup, but the user should
nevertheless
still be notified.
I disagree.
FWIW, I also disagree (and it looks like Bandan disagrees
On 07/10/15 16:59, Paolo Bonzini wrote:
On 10/07/2015 16:57, Laszlo Ersek wrote:
... In any case, please understand that I'm not campaigning for this
warning :) IIRC the warning was your (very welcome!) idea after I
reported the problem; I'm just trying to ensure that the warning match
On 07/09/15 20:32, Bandan Das wrote:
Paolo Bonzini pbonz...@redhat.com writes:
On 09/07/2015 08:43, Laszlo Ersek wrote:
On 07/09/15 08:09, Paolo Bonzini wrote:
On 09/07/2015 00:36, Bandan Das wrote:
Let userspace inquire the maximum physical address width
of the host processors; this can
On 07/09/15 08:09, Paolo Bonzini wrote:
On 09/07/2015 00:36, Bandan Das wrote:
Let userspace inquire the maximum physical address width
of the host processors; this can be used to identify maximum
memory that can be assigned to the guest.
Reported-by: Laszlo Ersek ler...@redhat.com
the corresponding capability.
Reported-by: Laszlo Ersek ler...@redhat.com
Signed-off-by: Bandan Das b...@redhat.com
---
linux-headers/linux/kvm.h | 1 +
target-i386/kvm.c | 6 ++
2 files changed, 7 insertions(+)
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index
prints a message to stderr if
KVM has the corresponding capability.
Reported-by: Laszlo Ersek ler...@redhat.com
Signed-off-by: Bandan Das b...@redhat.com
This is not entirely correct, because it doesn't take the PCI hole into
account.
Perhaps KVM could simply hide memory above the limit (i.e
On 07/09/15 11:27, Igor Mammedov wrote:
On Thu, 09 Jul 2015 09:02:38 +0200
Laszlo Ersek ler...@redhat.com wrote:
On 07/09/15 00:42, Bandan Das wrote:
If a Linux guest is assigned more memory than is supported
by the host processor, the guest is unable to boot. That
is expected, however
On 07/09/15 21:11, Bandan Das wrote:
Laszlo Ersek ler...@redhat.com writes:
...
First, see my comments on the KVM patch.
Second, ram_size is not the right thing to compare. What should be
checked is whether the highest guest-physical address that maps to RAM
can be represented
On 07/09/15 22:02, Bandan Das wrote:
Laszlo Ersek ler...@redhat.com writes:
...
Yes.
Without EPT, you don't
hit the processor limitation with your setup, but the user should
nevertheless
still be notified.
I disagree.
In fact, I think shadow paging code should also emulate
On 03/05/15 15:47, Mark Rutland wrote:
Several dts only list arm,cortex-a7-gic or arm,gic-400 in their GIC
compatible list, and while this is correct (and supported by the GIC
driver), KVM will fail to detect that it can support these cases.
This patch adds the missing strings to the VGIC
On 03/03/15 18:34, Alexander Graf wrote:
On 02/19/2015 11:54 AM, Ard Biesheuvel wrote:
This is a 0th order approximation of how we could potentially force
the guest
to avoid uncached mappings, at least from the moment the MMU is on.
(Before
that, all of memory is implicitly classified as
On 03/02/15 17:47, Paolo Bonzini wrote:
Also, we may want to invalidate the cache for dirty pages before
returning the dirty bitmap, and probably should do that directly in
KVM_GET_DIRTY_LOG.
I agree.
If KVM_GET_DIRTY_LOG is supposed to be atomic fetch and clear (from
userspace's aspect),
On 11/22/14 11:18, Christoffer Dall wrote:
On Fri, Nov 21, 2014 at 05:50:43PM -0800, Mario Smarduch wrote:
But virtio writes to guest memory directly and that appears to
work just fine. I read that code sometime back, and will need to revisit.
In any case, that's a QEMU implementation issue
On 11/17/2014 07:49 AM, Laszlo Ersek wrote:
On 11/17/14 16:29, Paolo Bonzini wrote:
On 17/11/2014 15:58, Ard Biesheuvel wrote:
Readonly memslots are often used to implement emulation of ROMs and
NOR flashes, in which case the guest may legally map these regions as
uncached.
To deal
On 11/20/14 21:10, Peter Maydell wrote:
On 20 November 2014 19:49, Jon Masters j...@redhat.com wrote:
On 11/20/2014 01:40 PM, Peter Maydell wrote:
The situation is not so bleak as this. See section B2.9 Mismatched
memory attributes in the ARMv8 ARM ARM (DDI0487A.d), which lays
out in some
it better than I can :)
FWIW,
Series
Reviewed-by: Laszlo Ersek ler...@redhat.com
I ported this series to a 3.17.0+ based kernel, and tested it. It works
fine. The ROM-like view of the NOR flash now reflects the previously
programmed contents.
Series
Tested-by: Laszlo Ersek ler...@redhat.com
Hello All,
I've been made an offer that I couldn't refuse :) to organize a Birds
of a Feather session concerning OVMF at the KVM Forum 2014.
Interested people, please sign up:
http://www.linux-kvm.org/page/KVM_Forum_2014_BOF#OVMF
Everyone else: apologies about the noise.
Thanks,
Laszlo
--
On 09/18/14 13:44, Andreas Färber wrote:
Hello Laszlo,
Am 18.09.2014 um 10:23 schrieb Laszlo Ersek:
I've been made an offer that I couldn't refuse :) to organize a Birds
of a Feather session concerning OVMF at the KVM Forum 2014.
Interested people, please sign up:
http://www.linux
a few patches from your
linaro-topic-virt-post-v7-roundup branch! :))
Acked-by: Laszlo Ersek ler...@redhat.com
Cheers
Laszlo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
-by: Alex Williamson alex.william...@redhat.com
Cc: Laszlo Ersek ler...@redhat.com
Cc: qemu-sta...@nongnu.org
---
target-i386/cpu.h |2 +-
target-i386/machine.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index
alex.william...@redhat.com
Cc: Laszlo Ersek ler...@redhat.com
Cc: qemu-sta...@nongnu.org
---
target-i386/cpu.h |2 +
target-i386/kvm.c | 101
-
2 files changed, 101 insertions(+), 2 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386
-by: Alex Williamson alex.william...@redhat.com
Cc: Laszlo Ersek ler...@redhat.com
Cc: qemu-sta...@nongnu.org
---
target-i386/cpu.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 6d008ab..9768be1 100644
--- a/target-i386
was already
slightly undersized for holding every possible MSR, so this patch
increases it beyond the 28 new entries necessary for MTRR state.
Signed-off-by: Alex Williamson alex.william...@redhat.com
Cc: Laszlo Ersek ler...@redhat.com
Cc: qemu-sta...@nongnu.org
---
target-i386/cpu.h |2
was already
slightly undersized for holding every possible MSR, so this patch
increases it beyond the 28 new entries necessary for MTRR state.
Signed-off-by: Alex Williamson alex.william...@redhat.com
Cc: Laszlo Ersek ler...@redhat.com
Cc: qemu-sta...@nongnu.org
---
target-i386/cpu.h |2
a number of comments -- feel free to address or ignore each as you see fit:
On 08/13/14 21:09, Alex Williamson wrote:
The SDM specifies (June 2014 Vol3 11.11.5):
On a hardware reset, the P6 and more recent processors clear the
valid flags in variable-range MTRRs and clear the E flag
On 08/14/14 00:06, Alex Williamson wrote:
On Wed, 2014-08-13 at 22:33 +0200, Laszlo Ersek wrote:
a number of comments -- feel free to address or ignore each as you see fit:
On 08/13/14 21:09, Alex Williamson wrote:
mappings which are now stale after reset. The result is that OVMF
rebooting
On 08/14/14 01:17, Laszlo Ersek wrote:
- With KVM, the lack of loading MTRR state from KVM, combined with the
(partial) storing of MTRR state to KVM, has two consequences:
- migration invalidates (loses) MTRR state,
I'll concede that migration *already* loses MTRR state (on KVM), even
On 04/26/14 11:40, Paolo Bonzini wrote:
Il 25/04/2014 09:39, Gerd Hoffmann ha scritto:
Anyone has plans to add smm support to kvm?
No plans, but it should be a Simple Matter Of Programming...
A good start would be to write unit tests for SMM that work with QEMU.
Well I don't know what
On 03/23/14 00:38, Michael Casadevall wrote:
On 03/22/2014 03:57 PM, Paolo Bonzini wrote:
Il 22/03/2014 13:23, Grant Likely ha scritto:
VM implementations SHOULD to implement persistent variables for
their UEFI implementation - with whatever constraints that may be
put on higher level tools.
On 03/08/14 12:41, Michael Casadevall wrote:
On 03/06/2014 05:46 PM, Paolo Bonzini wrote:
Il 06/03/2014 09:52, Robie Basak ha scritto:
On Sat, Mar 01, 2014 at 03:27:56PM +, Grant Likely wrote:
I would also reference section 3.3 (Boot Option Variables Default Boot
Behavior) and 3.4.1.1
at the work done in Tiano Core's
OvmfPkg, which has support for almost every QEMU feature thanks to the
work of Laszlo Ersek and Jordan Justen.
In particular, OvmfPkg has support for specifying a boot order in the VM
configuration (which maps to the -boot option in QEMU). In this case,
the UEFI boot
, emulation failure\n);
Based on earlier discussion
Reviewed-by: Laszlo Ersek ler...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/06/13 13:03, Paolo Bonzini wrote:
Il 05/12/2013 19:29, Laszlo Ersek ha scritto:
On 12/05/13 18:42, Paolo Bonzini wrote:
Il 05/12/2013 17:12, Laszlo Ersek ha scritto:
Hi,
I'm working on S3 suspend/resume in OVMF. The problem is that I'm getting
an
unexpected guest reboot for code
On 12/08/13 18:43, Laszlo Ersek wrote:
On 12/06/13 13:03, Paolo Bonzini wrote:
Thanks to your binary I now reproduced the issue and it looks like the
64-bit-16-bit switch works:
Thank you for spending (apparently more than a little) time on this!
qemu-system-x86-4081 [001
Hi,
I'm working on S3 suspend/resume in OVMF. The problem is that I'm getting an
unexpected guest reboot for code (LRET) that works on physical hardware. I
tried to trace the problem with ftrace, but I didn't get any mentions of
em_ret_far(). (Maybe I was looking in the wrong place.)
Please find
Small addition -- apologies for the self-followup:
On 12/05/13 17:12, Laszlo Ersek wrote:
I tried to trace the problem with ftrace, but I didn't get any mentions of
em_ret_far(). (Maybe I was looking in the wrong place.)
I applied the following small patch (to the original code):
diff --git
On 12/05/13 18:42, Paolo Bonzini wrote:
Il 05/12/2013 17:12, Laszlo Ersek ha scritto:
Hi,
I'm working on S3 suspend/resume in OVMF. The problem is that I'm getting an
unexpected guest reboot for code (LRET) that works on physical hardware. I
tried to trace the problem with ftrace, but I
On 12/05/13 18:42, Paolo Bonzini wrote:
diff --git a/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S
b/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S
index e59fd04..d1cac9d 100644
--- a/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S
+++
On 06/11/13 17:45, Michael S. Tsirkin wrote:
To summarize, there's a concensus now that generating ACPI
tables in QEMU is a good idea.
Two issues that need to be addressed:
- original patches break cross-version migration. Need to fix that.
- Anthony requested that patchset is merged
On 05/31/13 09:09, Jordan Justen wrote:
Why is updating the ACPI tables in seabios viewed as such a burden?
Either qemu does it, or seabios... (And, OVMF too, but I don't think
you guys are concerned with that. :)
I am :)
On the flip side, why is moving the ACPI tables to QEMU such an
On 05/31/13 10:13, Peter Stuge wrote:
ACPI bytes are obviously a function of QEMU configuration.
Precisely!
When we evaluate that (mathematical-sense) function in boot firmware, we
need to retrieve the function's arguments. Those arguments are bits of
QEMU configuration, as you say, and fw_cfg
On 05/31/13 16:08, David Woodhouse wrote:
On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
soapbox
Fork OVMF, drop the fat module, and just add GPL code. It's an easily
solvable problem.
Heh. Actually it doesn't need to be a fork. It's modular, and the FAT
driver is just a
On 05/31/13 16:38, Anthony Liguori wrote:
It's either Open Source or it's not. It's currently not.
I disagree with this binary representation of Open Source or Not. If it
weren't (mostly) Open Source, how could we fork (most of) it as you're
suggesting (from the soapbox :))?
I have a hard
On 05/31/13 17:43, Anthony Liguori wrote:
David Woodhouse dw...@infradead.org writes:
On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
soapbox
Fork OVMF, drop the fat module, and just add GPL code. It's an easily
solvable problem.
Heh. Actually it doesn't need to be a fork.
On 05/31/13 18:33, David Woodhouse wrote:
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 usable, and yes, that's not Open
Source. So in a sense
On 05/31/13 23:03, Jordan Justen wrote:
Of course, the fact that the current FAT driver is exclusionary for
free software projects is a point that is not lost on me. I just don't
agree that the best response to this is a GPL'd FAT driver.
What would you suggest?
Thank you,
Laszlo
--
To
On 05/30/13 11:23, David Woodhouse wrote:
On Wed, 2013-05-29 at 11:18 -0500, Anthony Liguori wrote:
Certainly an option, but that is a long-term project.
Out of curiousity, are there other benefits to using coreboot as a core
firmware in QEMU?
Is there a payload we would ever plausibly use
On 05/30/13 14:19, David Woodhouse wrote:
Yeah, but if we're shoving a lot of hardware-specific ACPI table
generation into the guest's firmware, instead of just doing it on the
qemu side where a number of us seem to think it belongs, then there *is*
a benefit to using Coreboot. When stuff
On 05/30/13 18:20, Jordan Justen wrote:
I think ACPI table generation lives in firmware on real products,
because on real products the firmware is the point that best
understands the actual hardware layout for the machine. In qemu, I
would say that qemu best knows the hardware layout, given
On 05/30/13 18:57, Jordan Justen wrote:
On Thu, May 30, 2013 at 9:41 AM, Laszlo Ersek ler...@redhat.com wrote:
On 05/30/13 18:20, Jordan Justen wrote:
I think ACPI table generation lives in firmware on real products,
because on real products the firmware is the point that best
understands
On 05/29/13 09:27, Paolo Bonzini wrote:
Il 29/05/2013 06:33, Rusty Russell ha scritto:
Paolo Bonzini pbonz...@redhat.com writes:
Il 28/05/2013 19:32, Michael S. Tsirkin ha scritto:
+
+switch (addr) {
+case offsetof(struct virtio_pci_common_cfg,
device_feature_select):
+
On 05/28/13 19:43, Paolo Bonzini wrote:
Il 28/05/2013 19:32, Michael S. Tsirkin ha scritto:
+
+switch (addr) {
+case offsetof(struct virtio_pci_common_cfg, device_feature_select):
+return proxy-device_feature_select;
Oh dear no... Please use defines like the rest of QEMU.
On 04/23/13 06:05, Rusty Russell wrote:
Laszlo Ersek ler...@redhat.com writes:
Hi,
(I'm not subscribed to either list,)
using the word descriptor is misleading in the following sections:
Yes, I like the use of 'descriptor chains'. This is a definite
improvement.
Here's the diff I
Hi,
(I'm not subscribed to either list,)
using the word descriptor is misleading in the following sections:
2.4.1.2 Updating The Available Ring
[...] However, in general we can add many descriptors before we
update the idx fi eld (at which point they become visible to the
device), so
(Please keep me CC'd on any followup; I'm not subscribed. Thanks.)
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
qemu-io.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/qemu-io.c b/qemu-io.c
index ffa62fb..938b20c 100644
--- a/qemu-io.c
+++ b/qemu-io.c
On 01/24/12 21:05, Markus Armbruster wrote:
Laszlo Ersekler...@redhat.com writes:
(Please keep me CC'd on any followup; I'm not subscribed. Thanks.)
Patch is fine, but it needs to go toqemu-de...@nongnu.org.
Ooops... Thanks!
Laszlo
--
To unsubscribe from this list: send the line
84 matches
Mail list logo
