On 29/07/2015 21:07, Alex Williamson wrote:
diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
index e275013..dc0a84a 100644
--- a/arch/x86/kvm/mtrr.c
+++ b/arch/x86/kvm/mtrr.c
@@ -672,15 +672,16 @@ u8 kvm_mtrr_get_guest_memory_type(struct kvm_vcpu
*vcpu, gfn_t gfn)
if
On 16/07/2015 06:10, Alex Williamson wrote:
On Thu, 2015-07-16 at 03:25 +0800, Xiao Guangrong wrote:
From: Xiao Guangrong guangrong.x...@intel.com
Currently code uses default memory type if MTRR is fully disabled,
fix it by using UC instead
Signed-off-by: Xiao Guangrong
On 23/07/2015 08:29, Xiao Guangrong wrote:
In fact this is the same quirk already implemented for SVM as
KVM_QUIRK_CD_NW_CLEARED, so we can reuse the bit.
Sounds good to me. I will drop the new bit and reuse as your suggestion.
And i think we need document this whole staff in API.txt ...
On 23/07/2015 11:46, David Woodhouse wrote:
On Tue, 2014-11-04 at 14:32 -0800, Jordan Justen wrote:
On Tue, Nov 4, 2014 at 9:28 AM, Andrew Fish af...@apple.com wrote:
So my 1st question is why do you need to mix calling conventions,
and depend
on EFIAPI for interoperability. Why not just
On 15/07/2015 21:25, Xiao Guangrong wrote:
From: Xiao Guangrong guangrong.x...@intel.com
Current firmware depends on WB to fast boot, please refer to
https://lkml.org/lkml/2015/7/12/115
Let's us WB if CR0.CD is set to make this kind of firmware happy
This quirk can be dropped by
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 KB worth of DXE and UEFI
drivers --
On 08/07/2015 23:03, Laszlo Ersek wrote:
On 07/08/15 22:36, Ryan Harkin wrote:
I have an alias in my ~/.gitconfig file:
[alias]
amm=am --ignore-whitespace --ignore-space-change
Then I use git amm to apply patches and that seems to work most of the
time.
But I suspect your method
On 06/06/2015 01:47, Laszlo Ersek wrote:
This half of the series would actually apply to
PcAtChipsetPkg/PciHostBridgeDxe itself, and it would be possible to
clone the driver for OvmfPkg only at the end of the first half.
Yes, please... :)
Paolo
On 03/06/2015 13:14, Laszlo Ersek wrote:
On 06/03/15 11:50, Gao, Liming wrote:
Hi, all
Now, EDKII project Git mirror is ready in GitHub (https://
https://github.com/tianocoregithub.com/tianocore
https://github.com/tianocore). There are EDKII project Repo and each
package Repo. After
On 03/06/2015 13:57, Laszlo Ersek wrote:
Bisectability would be extremely painful, because bisection on the
master repository would leave you at the single huge commit where you
atomically update all subpackages. You would have no clue of how to
bisect _within_ that atomic update, in
On 04/05/2015 15:58, Laszlo Ersek wrote:
I audited all PCDs used by PiSmmCpuDxeSmm carefully. Most of them are
fixed or feature PCDs, fine. However, there are two dynamic PCDs that
carry important information (and we can't just go with a default):
- PcdCpuConfigContextBuffer
-
On 04/05/2015 15:58, Laszlo Ersek wrote:
So here's the *specific* issues I'm facing (and need help with):
* Problem #1 for task (4):
Because Quark is 32-bit only, the (mostly assembly) code under
OvmfPkg/QuarkPort/PiSmmCpuDxeSmm/Ia32 that (partly) constitutes the
SMM entry vector does not
On 04/05/2015 20:03, Laszlo Ersek wrote:
However, the point where it ultimately breaks, I think, is the
individual runtime drivers that communicate with their privileged SMM
counterparts. The communication happens via serializing a binary
message, and then raising an SMI.
Minimally in the
A friendly reminder that KVM Forum 2015 accepts proposal submissions
until next Friday.
Thanks on behalf of the KVM Forum 2015 Program Committee.
Paolo
On 11/03/2015 18:55, Paolo Bonzini wrote:
=
KVM Forum 2015: Call
On 24/04/2015 13:56, Yao, Jiewen wrote:
BTW: I am not sure how QEMU emulate SMI. Does SMI can be trigger by
0xB2 port? And CPU will run to SMBASE in real mode?
Yes, operation is the same.
Paolo
--
One dashboard for
On 21/04/2015 22:31, Laszlo Ersek wrote:
typedef enum {
EfiLockUninitialized = 0,
EfiLockReleased = 1,
EfiLockAcquired = 2
} EFI_LOCK_STATE;
typedef struct {
EFI_TPL Tpl;
EFI_TPL OwnerTpl;
EFI_LOCK_STATE Lock;
} EFI_LOCK;
VOID
EFIAPI
=
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 06/03/2015 13:35, Laszlo Ersek wrote:
(And, indeed, I'm not forgetting about the miserable FAT driver either.
I have absolutely no idea why that driver has to live in a separate
repo, presenting upstream developers with technical hurdles when they
want to build their entire tree from
On 07/03/2015 00:04, Jordan Justen wrote:
The other option is to call
http://dir.gmane.org/gmane.comp.bios.tianocore.devel the official
archive.
I don't think that archive is complete. I asked that GMANE create the
group, but getting the archive from SourceForge looked painful enough
that I
On 30/01/2015 11:41, tiger...@zhaoxin.com wrote:
So, my question is:
BIOS provides MADT table, OS will use APIC mode.
So OS will re-configure LINT0 / LINT1 as other mode?
Yes. Typically LINT1 will remain NMI, while the OS will mask LINT0 and
configure the IOAPIC to deliver ISA interrupts
On 19/12/2014 12:27, tiger...@via-alliance.com wrote:
Hi, experts:
I found an OptionROM example for CirrusLogic5430 display card in edkii
source code package.
So where could I buy this product?
It seems it is a very old PCI display card.
I don't think the driver has been tested ever
On 04/12/2014 17:00, Scott Duplichan wrote:
]
]#define PCI_CF8_LIB_ADDRESS(Bus,Device,Function,Offset) \
] (((Offset) 0xff) | (((Function) 0x07) 8) | (((Device) 0x1f)
16) | (((Bus) 0xff) 24))
I think something more like this...
#define
On 02/12/2014 13:42, Olivier Martin wrote:
Now, BaseTools is part of EDK2 source tree. Should BaseTools use
ProcessorBind.h from MdePkg?
Note that it's possible that BaseTools is compiled for a different
architecture than MdePkg. Unifying the files can be useful, but perhaps
the BaseTools
On 22/11/2014 07:35, Laszlo Ersek wrote:
The 'LUN encoding in CDB' feature of UefiScsiLib violates the SBC-3 and
causes actual breakage on SCSI disks with nonzero LUNs that are emulated
by QEMU.
The first patch makes this (very small) part of UefiScsiLib dependent on
a new MdePkg Feature
On 14/11/2014 14:40, Laszlo Ersek wrote:
Now where is my thought process wrong? You might want to add an assert
somewhere.
I don't think your thought process is wrong. I think I'm being exactly
as right (or as wrong) as SeaBIOS under all cases, which is what I was
aiming for :)
On 07/11/2014 17:40, Gabriel Somlo wrote:
I don't know how I could bring a bus number into the mix (I just
assume the bus number is 0 and stop after the first device path node,
which happens to match the SeaBIOS (pci-parent == NULL) case.
But how would I (and should I even try) to port the
On 07/11/2014 18:31, Gabriel Somlo wrote:
I don't care about non-root ports at all, personally. But if I'm doing
this for my own ulterior motives (below), I feel I should do it in the
best way the surrounding infrastructure permits it. I'm definitely NOT
signing up to ADD non-root port support
,
with a FIXME comment stating we should look for a way to initialize
present devices programmatically rather than hard-code typical
devices we expect to see configured by QEMU
- cloned edk2 with these patches on top available on github
https://github.com/gsomlo/edk2
Reviewed-by: Paolo
On 10/24/2014 05:33 AM, Gabriel L. Somlo wrote:
This patch removes hard-coded assumptions about the presence of a PIIX4
chipset, and dynamically probes for the presence of either PIIX4 or Q35.
Patches 1-6 are candidates for upstream right now (modulo any feedback,
of course). Patch 7,
On 10/23/2014 11:30 AM, Laszlo Ersek wrote:
On 10/22/14 22:39, Paolo Bonzini wrote:
On 10/22/2014 09:17 PM, Laszlo Ersek wrote:
Sigh. If I set PcdPlatformBootTimeOut to 0, then the progress bar is not
shown, but a user keypress is also not picked up.
Therefore the minimum I could set
Yes, the default is zero. However, you would get to a shell on an
otherwise unconfigured system, and you could enter the boot menu via
OsIndications. It's what SeaBIOS does, and it is not very much
different from what you'd do for machines you don't have physical access to.
If I
On 10/22/2014 09:17 PM, Laszlo Ersek wrote:
Sigh. If I set PcdPlatformBootTimeOut to 0, then the progress bar is not
shown, but a user keypress is also not picked up.
Therefore the minimum I could set is 1 second, which would increase the
boot time by 0.7 seconds. Let me know how you want
Il 29/09/2014 09:26, Gerd Hoffmann ha scritto:
+ mtrr: your CPUs had inconsistent fixed MTRR settings
+ mtrr: your CPUs had inconsistent variable MTRR settings
+ mtrr: your CPUs had inconsistent MTRRdefType settings
+ mtrr: probably your BIOS does not setup all CPUs.
+ mtrr: corrected
Il 24/09/2014 23:09, Jordan Justen ha scritto:
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
OvmfPkg/Library/LoadLinuxLib/Linux.c| 6 +++---
OvmfPkg/PlatformPei/MemDetect.c | 2 +-
Il 29/09/2014 09:22, Gerd Hoffmann ha scritto:
The one thing I'm a bit unsure about is PciInitializationQ35
(BdsPlatform.c);
In PciInitializationPIIX (which used to be plain PciInitialization before
this patch), there's a whole bunch of other devices (ide, video, network,
etc.) being
Il 29/09/2014 14:07, Laszlo Ersek ha scritto:
Apparently so, for 00:01.3 on the PIIX4.
But for other PCI devices, I think it's writeable, isn't it? (Of course
the devices-related code in this function should go away completely, if
possible. git-blame is probably helpful here.)
No, it's
Il 22/09/2014 00:43, Laszlo Ersek ha scritto:
// Bus 0, Device 1, Function 0 - PCI to ISA Bridge
//
PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x3c), 0x00);
PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x60), 0x0b); // LNKA routing target
PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x61), 0x0b); // LNKB
Il 19/09/2014 16:17, Ard Biesheuvel ha scritto:
(**) Ard's patches for the upstream host kernel (== KVM) have been...
ugh, not sure... applied to a maintainer tree? Ard? :)
Some are in kvm/master, which I think means to should go into the next
3.17-rc, although I haven't seen much
Il 14/09/2014 15:06, Laszlo Ersek ha scritto:
+ } else {
+Accumulator -= gMetronome-TickPeriod;
+if (Counter == MAX_UINT64) {
+ CoreInternalWaitForTick (Counter);
+ CoreInternalWaitForTick (1);
+} else {
+ CoreInternalWaitForTick
Il 14/09/2014 16:45, Paolo Bonzini ha scritto:
Il 14/09/2014 15:06, Laszlo Ersek ha scritto:
+ } else {
+Accumulator -= gMetronome-TickPeriod;
+if (Counter == MAX_UINT64) {
+ CoreInternalWaitForTick (Counter);
+ CoreInternalWaitForTick (1
Il 11/09/2014 18:35, Gabriel L. Somlo ha scritto:
Can you configure Chamaleon to avoid the boot prompt?
Yes. After doing that, usb starts working once OS X is fully booted.
Works with either piix or q35 just fine.
Does this mean it's likely to be an OVMF uhci/ehci issue specific to Q35 ?
Il 11/09/2014 19:11, Gabriel L. Somlo ha scritto:
On Thu, Sep 11, 2014 at 06:40:38PM +0200, Paolo Bonzini wrote:
Il 11/09/2014 18:35, Gabriel L. Somlo ha scritto:
Can you configure Chamaleon to avoid the boot prompt?
Yes. After doing that, usb starts working once OS X is fully booted.
Works
Il 10/09/2014 16:06, Gabriel L. Somlo ha scritto:
If it's in QEMU, it's only tickled by the OVMF + OSX combination.
Fedora works (around it) fine, and everyone's happy when using
SeaBIOS (and Chameleon, in OSX's case).
BTW, when I do something like this:
-usb -device
with a straight face when asked to upgrade
NASM? This is not a bug that would have to be filed, it's a substantial
feature request...
Paolo
On 31 авг. 2014 г., at 20:16, Paolo Bonzini pbonz...@redhat.com wrote:
Il 30/08/2014 08:47, Jordan Justen ha scritto:
All,
Sergey reported that XCLANG
Il 30/08/2014 08:47, Jordan Justen ha scritto:
All,
Sergey reported that XCLANG was able to build and link with my latest
version. (Apparently he still has issues booting OVMF, but I don't
think it is specifically due to NASM Thunk16.)
Therefore, I'll commit the NASM series now with
Il 26/08/2014 18:49, Laszlo Ersek ha scritto:
The problem is that a number of tables are not linked into the RSDT,
they are referenced by other tables. Basically, all the pointer fields
in all tables that are updated (relocated / absolutized) by AddPointer
commands, point *potentially* to
Il 26/08/2014 03:03, Laszlo Ersek ha scritto:
The only way you could reliably fish out tables, operation regions etc.
from the qemu payload would be to write a near-full ACPI interpreter.
The goal of the interface is the polar opposite, ie. to require the
firmware to know the least possible
Il 06/08/2014 12:34, Laszlo Ersek ha scritto:
So no, you can't ship an OVMF binary (or source tarball) that contains
the FAT driver, bundled as part of the GPLv2 (+compatible) QEMU
distribution, either in source or in binary form.
What Laszlo said is mostly my understanding too (IANAL etc.).
The deadline is coming in three days!
Paolo
Il 16/06/2014 18:07, Paolo Bonzini ha scritto:
=
KVM Forum 2014: Call For Participation
October 14-16, 2014 - Congress Centre Düsseldorf - Düsseldorf, Germany
(All submissions must
Il 24/07/2014 21:27, Jordan Justen ha scritto:
You can add
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
to this series, and:
BuildEnv: remove useless check before setting $WORKSPACE
Do you have these in a public edk2 repo based on
https://github.com/tianocore/edk2?
I'm pushing
Il 04/07/2014 10:20, Paolo Bonzini ha scritto:
Ok to apply the patches, since they work for all packaging scenarios?
Ping?
Paolo
Paolo
--
Want fast and easy access to all the code in your enterprise? Index
Il 24/06/2014 11:55, Paolo Bonzini ha scritto:
As long as $EDK_TOOLS_PATH is properly set, the BaseTools/ directory
is not necessary in the workspace. The BuildEnv file itself suggests
setting the variable if BaseTools/ is not available.
However, this only works if the user also sets
Il 24/06/2014 11:55, Paolo Bonzini ha scritto:
As long as $EDK_TOOLS_PATH is properly set, the BaseTools/ directory
is not necessary in the workspace. The BuildEnv file itself suggests
setting the variable if BaseTools/ is not available.
However, this only works if the user also sets
Il 27/06/2014 19:16, Jordan Justen ha scritto:
On Thu, Jun 26, 2014 at 2:33 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 25/06/2014 22:12, Jordan Justen ha scritto:
At least EfiRom is generic and not only of use during an edk2 build. I
suppose others could be useful (such as PatchPcdValue
Il 25/06/2014 22:12, Jordan Justen ha scritto:
At least EfiRom is generic and not only of use during an edk2 build. I
suppose others could be useful (such as PatchPcdValue or VolInfo).
I think all these tools are too generically named to be installed in
the main bin path. (Even if they
Il 24/06/2014 22:27, Laszlo Ersek ha scritto:
- (minor nit) I suggested MdePkg.dec, not MdePkg.dsc, but I guess their
availability is interchangeable for this purpose, so OK;
Heh I didn't remember exactly which one you suggested and didn't have
network access when I wrote the patch. :)
-
-by: Laszlo Ersek ler...@redhat.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
edksetup.sh | 46 --
1 file changed, 44 insertions(+), 2 deletions(-)
diff --git a/edksetup.sh b/edksetup.sh
index
and explained to the user.
Paolo
Paolo Bonzini (2):
edksetup.sh: Look for BuildEnv under EDK_TOOLS_PATH
edksetup.sh: Ensure that WORKSPACE points to the top of an edk2 checkout
edksetup.sh | 51 ---
1 file changed, 48 insertions(+), 3 deletions
for BaseTools and OVMF is completely
different.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek ler...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
edksetup.sh | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/edksetup.sh b
if
there are no BaseTools inside $WORKSPACE.
What you are saying makes sense, but I was not sure of how people are
using these scripts. If you say it's okay, I can change it to look at
EDK_TOOLS_PATH first.
Paolo
-Jordan
On Wed, Jun 25, 2014 at 1:37 AM, Paolo Bonzini pbonz...@redhat.com wrote
-by: Paolo Bonzini pbonz...@redhat.com
--- a/edksetup.sh
+++ b/edksetup.sh
@@ -35,11 +35,14 @@
function SetupEnv()
{
- if [ -z $WORKSPACE ]
+ if [ -n $WORKSPACE ]
then
-. BaseTools/BuildEnv $*
- else
. $WORKSPACE/BaseTools/BuildEnv $*
+ elif [ -n $EDK_TOOLS_PATH
itself and does not even try to use
the preset $EDK_TOOLS_PATH. Remove the check that fails, as it does
not have any practical benefit.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
--- a/BaseTools/BuildEnv
+++ b/BaseTools/BuildEnv
Il 24/06/2014 13:33, Laszlo Ersek ha scritto:
The code being removed checks if ./BaseTools/BuildEnv is the same
script file (by device and inode numbers) as the one executing (whether
forked or sourced). This seems to be the polar opposite of what
EDK_TOOLS_PATH is supposed to enable -- an
Il 18/06/2014 05:08, Gao, Liming ha scritto:
If you have any comments, please let me know.
Besides, Jordan proposes to merge those two BaseTools. After it is done,
such sync will not be required.
I think there is a benefit in keeping the two repositories together.
There is also a benefit in
Check for the presence of a well-known file in the checkout,
in order to detect an incorrect setting of $WORKSPACE.
Only print the new message if sourcing BuildEnv succeeds.
Suggested-by: Laszlo Ersek ler...@redhat.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo
Il 24/06/2014 13:33, Laszlo Ersek ha scritto:
The code being removed checks if ./BaseTools/BuildEnv is the same
script file (by device and inode numbers) as the one executing (whether
forked or sourced). This seems to be the polar opposite of what
EDK_TOOLS_PATH is supposed to enable -- an
=
KVM Forum 2014: Call For Participation
October 14-16, 2014 - Congress Centre Düsseldorf - Düsseldorf, Germany
(All submissions must be received before midnight July 27, 2014)
Il 07/05/2014 04:37, Laszlo Ersek ha scritto:
I'm not familiar with i2c-bus, but from the qemu code, it looks like you
should check the output of info mtree. The pc_init1() function calls
piix4_pm_init() with smb_io_base=0xb100. Again from a superficial
reading of the code, this should later
for
GraphicsConsoleDxe, 2014-03-22), we need to specify a non-null
instance of PcdLib.
This patch unbreaks the CSM VideoDxe module for OvmfPkg.
Contributed-under: TianoCore Contribution Agreement 1.0
Cc: Jordan Justen jordan.l.jus...@intel.com
Cc: Laszlo Ersek ler...@redhat.com
Signed-off-by: Paolo
Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c | 24 +++-
1 file changed, 7 insertions(+), 17 deletions(-)
diff --git a/OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c
b/OvmfPkg/Library/PlatformBdsLib
Il 31/03/2014 18:26, Laszlo Ersek ha scritto:
(1) What is the OFW format that qemu produces for a passthru (=host)
device? If it has a third node, I think I'd prefer a specific check. If
it only comes with two nodes (and we want to be able to match it), then
the catchall is unavoidable.
It
Il 26/02/2014 22:59, Laszlo Ersek ha scritto:
Basically it stays completely in PlatformConfigDxe.
I'm asking because threading a rename through such a rebase is a big
pain. Too bad I'd lose the nice (I hope!) structure of these patches,
ie. the progress and the thought process. Perhaps if I
Il 29/01/2014 00:10, Laszlo Ersek ha scritto:
(We used to keep the prebuilt page tables too in read-only flash, but
KVM didn't really like to have them there, because it wanted to write
the Accessed bits in the page table entries, even if they were all
pre-set to 1. I can't recall the exact
Il 29/01/2014 00:10, Laszlo Ersek ha scritto:
Please note though that OVMF code to actually honor this setting will
only be written/added once the basic S3 functionality is complete.
(Which it is not, for the time being.)
Naturally, you can try to convince Jordan to implement that ASAP :)
I
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 (LRET) that works on physical hardware. I
Il 06/12/2013 13:03, Paolo Bonzini ha scritto:
The page tables are, ahem, crap:
000c000: 6750 fe01 gP..
000c010:
000c020:
000c030
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 didn't get any mentions of
em_ret_far().
Il 25/11/2013 20:45, Laszlo Ersek ha scritto:
From looking at hw/block/pflash_cfi01.c, it seems that the guest can
interrogate the flash device about its size (nb_blocs is stored in
cfi_table starting at 0x2D, and cfi_table can be queried by command 0x98
in pflash_read()). So, if the guest
Il 26/11/2013 14:53, Laszlo Ersek ha scritto:
IIUC in the case of OVMF the guest just knows that there are multiple
devices backing the range. Is that right?
No, the guest (the flash driver) is unaware of that. It could know if it
wanted to, but it doesn't care. It cares about a base
Il 21/11/2013 23:21, Laszlo Ersek ha scritto:
Split the variable store off to a separate file when SPLIT_VARSTORE is
defined.
Even in this case, the preexistent PCDs' values don't change. Qemu must
take care of contiguously mapping NVVARSTORE.fd + OVMF.fd so that when
concatenated they end
Il 22/11/2013 12:46, Laszlo Ersek ha scritto:
Also, I see a command line compatibility problem, especially if one
wants OVMF.fd to become the default firmware.
I don't understand. If you use the un-split build, you use the original
command line (single -pflash or -drive if=pflash option).
Il 07/11/2013 23:23, Laszlo Ersek ha scritto:
On 11/07/13 22:24, Marcel Apfelbaum wrote:
Why pci-hole and system.flash collide? IMHO we should not play with
priorities here, better solve the collision.
What about this beautiful series? It produces
memory
-000f
Il 08/11/2013 16:08, Marcel Apfelbaum ha scritto:
Actually, as I see, the default behavior of system memory region
is to use unassigned_mem_ops that has valid.accepts method returning
false (no read/write methods). I don't see that read all-ones/ignore
writes is implemented.
Right, it's
Il 07/11/2013 22:12, Laszlo Ersek ha scritto:
-7ffe (prio 0, RW): system
[...]
6000- (prio 0, RW): alias pci-hole @pci
6000-
[...]
ffe0- (prio 0, R-): system.flash
[...]
Il 01/09/2013 11:17, Gleb Natapov ha scritto:
This makes me think are there other places where gfn_to_hva() was
used, but gfn_to_hva_prot() should have been?
- kvm_host_page_size() looks incorrect. We never use huge page to map
read only memory slots currently.
- kvm_handle_bad_page()
Il 23/09/2013 15:37, Olivier Martin ha scritto:
+ // Declare the Virtio BlockIo device
+ Status = VirtioMmioInstallDevice (ARM_FVP_BASE_VIRTIO_BLOCK_BASE,
ImageHandle);
+ if (EFI_ERROR (Status)) {
+DEBUG ((EFI_D_ERROR, ArmFvpDxe: Failed to install Virtio block
device\n));
+ }
Il 17/09/2013 18:54, Olivier Martin ha scritto:
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin olivier.mar...@arm.com
---
.../ArmVExpressPkg/ArmFvpDxe/ArmFvpDxe.c | 49
+++-
.../ArmVExpressPkg/ArmFvpDxe/ArmFvpDxe.inf
Il 19/09/2013 22:30, Laszlo Ersek ha scritto:
In a nutshell, VirtioPciSetDeviceStatus() breaks the interface contract
of VIRTIO_DEVICE_PROTOCOL.WriteDevice(). The former targets a common
virtio field, but the latter provides access to device-specific fields.
Consequently, the virtio device is
Il 19/09/2013 15:56, Olivier Martin ha scritto:
+ // Note: We should detect if the Device has MSI-X capability. In case the
device has
+ // MSI-X capability then the offset would be 24.
+ Device-DeviceSpecificConfigurationOffset = 20;
The offset does not move from 20 to 24 unless
Il 20/09/2013 18:10, Laszlo Ersek ha scritto:
On 09/20/13 17:37, Paolo Bonzini wrote:
Il 17/09/2013 18:54, Olivier Martin ha scritto:
diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-AEMv8Ax4.fdf
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-AEMv8Ax4.fdf
index 4210e6c
Il 03/09/2013 15:41, Laszlo Ersek ha scritto:
Short summary for Gleb and Paolo:
- qemu master + kvm_intel (3.10) run both OVMF/master and
OVMF/master+SeaBIOS/master CSM well, including booting a legacy OS
- qemu master + TCG spirals into an endless loop when trying to boot a
legacy OS
Il 02/09/2013 12:07, Gleb Natapov ha scritto:
On Mon, Sep 02, 2013 at 06:00:39PM +0800, Xiao Guangrong wrote:
On 09/02/2013 05:25 PM, Gleb Natapov wrote:
On Mon, Sep 02, 2013 at 05:20:15PM +0800, Xiao Guangrong wrote:
On 08/30/2013 08:41 PM, Paolo Bonzini wrote:
Page tables in a read-only
Il 02/09/2013 12:11, Gleb Natapov ha scritto:
Got it, thanks for your explanation.
BTW, if you and Paolo are busy on other things, i am happy to fix these
issues. :)
I am busy with reviews mostly :). If you are not to busy with lockless
write protection then fine with me. Lest wait
Il 02/09/2013 11:25, Gleb Natapov ha scritto:
On Mon, Sep 02, 2013 at 05:20:15PM +0800, Xiao Guangrong wrote:
On 08/30/2013 08:41 PM, Paolo Bonzini wrote:
Page tables in a read-only memory slot will currently cause a triple
fault because the page walker uses gfn_to_hva and it fails
Il 30/08/2013 11:37, Laszlo Ersek ha scritto:
Disclaimer: I don't know what I'm talking about.
No problem. :)
So, Jordan's patch for OVMF (SVN r14494) builds the page tables (and
finally writes the root to CR3) in a phase when paging is not enabled
yet in the VM.
Again, I have no clue,
is readonly, and later check it when updating the accessed and dirty bits.
Cc: sta...@vger.kernel.org
Cc: g...@redhat.com
Cc: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
CCing to stable@ since the regression was introduced
Il 30/08/2013 19:39, Jordan Justen ha scritto:
However, if you guys can figure out a patch for
UefiCpuPkg/ResetVector/Vtf0/Ia32/Flat32ToFlat64.asm so that it builds
the page tables in RAM (and removing the page table Python code), that
would also work.
That path is not quite how it needs
Il 02/05/2013 17:13, Jordan Justen ha scritto:
On Thu, May 2, 2013 at 6:33 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 18/12/2012 05:15, Gao, Liming ha scritto:
Yes. I plan to sync EDKII BaseTools in next year Q1.
When I have the detail schedule, I will send notify email to you.
Thanks
Il 29/04/2013 01:52, Laszlo Ersek ha scritto:
I inserted the following rule at the second position manually:
Chain POSTROUTING (policy ACCEPT 79 packets, 6075 bytes)
pkts bytes target prot opt in out source
destination
00 MASQUERADE tcp
Il 08/03/2013 01:14, Andrew Fish ha scritto:
We just ran into an issue that I thought was worth sharing with the
group. We just updated our compiler and a memory test got optimized
away. At first we thought it was a compiler bug. But then we were
informed that in the C language the dereference
1 - 100 of 115 matches
Mail list logo
