On 01/06/16 14:39, Igor Mammedov wrote:
> On Tue, 5 Jan 2016 18:22:33 +0100
> Laszlo Ersek wrote:
>
>> On 01/05/16 18:08, Igor Mammedov wrote:
>>> On Mon, 4 Jan 2016 21:17:31 +0100
>>> Laszlo Ersek wrote:
>>>
>>>> Michael CC'd me on
On 01/05/16 18:08, Igor Mammedov wrote:
> On Mon, 4 Jan 2016 21:17:31 +0100
> Laszlo Ersek 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 12/30/15 20:52, M
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" 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&
ginal commit b18d5431acc7.
Cc: Paolo Bonzini
Cc: Jordan Justen
Cc: Janusz Mocek
Cc: Alex Williamson
Cc: Xiao Guangrong
Signed-off-by: Laszlo Ersek
---
arch/x86/kvm/x86.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index a24b
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 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. But
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
> Cc: Radim Krčmář
> Signed-off-by: Paolo Bonzini
> ---
> arch/x86/kvm/emulate.c |
On 11/02/15 10:32, Paolo Bonzini wrote:
>
>
> On 31/10/2015 20:50, Laszlo Ersek wrote:
>> Tested-by: Laszlo Ersek
>
> Thanks Laszlo, I applied patches 1 and 2 (since your "part 2" never was :)).
>
> Paolo
>
Thanks.
Since you can rebase the queue fr
ted mode
>
> 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 Er
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
y, not the
guest's SMRAM.
Fixes: b10d92a54dac25a6152f1aa1ffc95c12908035ce
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Jordan Justen
Cc: Michael Kinney
Cc: sta...@vger.kernel.org
Signed-off-by: Laszlo Ersek
---
arch/x86/kvm/emulate.c | 37 ++---
1 file changed, 30 i
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
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
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:
>
>
>
> Wel
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
>>> mac
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 - 100
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
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:vcp
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:
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 bef
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
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 SE
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 a
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 completel
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
>>>> report
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
On 07/09/15 22:02, Bandan Das wrote:
> Laszlo Ersek writes:
> ...
>> Yes.
>>
>>> Without EPT, you don't
>>> hit the processor limitation with your setup, but the user should
>>> nevertheless
>>> still be notified.
>>
>> I d
On 07/09/15 21:11, Bandan Das wrote:
> Laszlo Ersek 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
On 07/09/15 20:32, Bandan Das wrote:
> Paolo Bonzini 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
On 07/09/15 11:27, Igor Mammedov wrote:
> On Thu, 09 Jul 2015 09:02:38 +0200
> Laszlo Ersek 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 una
indicating the user
>> what went wrong. This change prints a message to stderr if
>> KVM has the corresponding capability.
>>
>> Reported-by: Laszlo Ersek
>> Signed-off-by: Bandan Das
>
> This is not entirely correct, because it doesn't take the PCI hole
err if
> KVM has the corresponding capability.
>
> Reported-by: Laszlo Ersek
> Signed-off-by: Bandan Das
> ---
> 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/
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.
>>
>&g
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
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 classif
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 aspec
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
On 11/20/14 21:10, Peter Maydell wrote:
> On 20 November 2014 19:49, Jon Masters 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 detai
he memslot) can be considered barriers.
I hope this is acceptable for the time being...
Thanks
Laszlo
>
> - Mario
>
> 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 wr
attachment,
it has a very verbose commit message.
Anyway, I'll let others explain; they can word it better than I can :)
FWIW,
Series
Reviewed-by: Laszlo Ersek
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
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.
>>
>
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
--
orts due to funky
register writeback instructions don't set the ISV, hence the code used
to turn its back on the clear WnR. (Apologies for explaining it to
myself publicly.) We now ignore the ISV and key off the WnR only.
You're awesome, Ard. (And now you can drop a few patches from you
ed.
>
> Note that the entries array used by both functions 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
> Cc: Laszlo Ersek
> Cc: qemu-sta.
ed.
>
> Note that the entries array used by both functions 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
> Cc: Laszlo Ersek
> Cc: qemu-sta.
a process that is nearly instant on
> the initial boot.
>
> Signed-off-by: Alex Williamson
> Cc: Laszlo Ersek
> Cc: qemu-sta...@nongnu.org
> ---
>
> target-i386/cpu.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/target-i386/cpu.c b/
d the 28 new entries necessary for MTRR state.
>
> Signed-off-by: Alex Williamson
> Cc: Laszlo Ersek
> Cc: qemu-sta...@nongnu.org
> ---
>
> target-i386/cpu.h |2 +
> target-i386/kvm.c | 101
> -
> 2 files chang
consistently.
>
> Signed-off-by: Alex Williamson
> Cc: Laszlo Ersek
> 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/targ
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 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 r
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 fl
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 wh
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 l
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)
hat for a _portable VM disk
>> image_, the OS on it cannot assume that this functionality is present.
>
> This is already the case for most OSes. Otherwise you wouldn't be able
> to move a hard disk from a (physical) machine to another.
>
> I strongly suggest tha
i, (uint64_t)run->internal.data[i]);
> }
> -} else {
> -fprintf(stderr, "\n");
> }
> if (run->internal.suberror == KVM_INTERNAL_ERROR_EMULATION) {
> fprintf(stderr, "emulation failure\n");
>
Based on earlier disc
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!
>
>&g
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 OVM
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
> +++ b/MdeM
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
>
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):
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
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 merg
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 un
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
On 05/31/13 17:43, Anthony Liguori wrote:
> David Woodhouse writes:
>
>> On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
>>>
>>>
>>>
>>> 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 m
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 16:08, David Woodhouse wrote:
> On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
>>
>>
>>
>> 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
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 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 is
On 05/30/13 18:57, Jordan Justen wrote:
> On Thu, May 30, 2013 at 9:41 AM, Laszlo Ersek 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 th
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, give
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 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 eve
On 05/29/13 09:27, Paolo Bonzini wrote:
> Il 29/05/2013 06:33, Rusty Russell ha scritto:
>> Paolo Bonzini writes:
>>> Il 28/05/2013 19:32, Michael S. Tsirkin ha scritto:
+
+switch (addr) {
+case offsetof(struct virtio_pci_common_cfg,
device_feature_sele
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
On 04/23/13 06:05, Rusty Russell wrote:
> Laszlo Ersek 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&
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), s
On 01/24/12 21:05, Markus Armbruster wrote:
Laszlo Ersek writes:
(Please keep me CC'd on any followup; I'm not subscribed. Thanks.)
Patch is fine, but it needs to go to.
Ooops... Thanks!
Laszlo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the
(Please keep me CC'd on any followup; I'm not subscribed. Thanks.)
Signed-off-by: Laszlo Ersek
---
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
@@ -1118
84 matches
Mail list logo
