Re: [edk2] [PATCH 2/3] KVM: MTRR: simplify kvm_mtrr_get_guest_memory_type

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 (i

Re: [edk2] Enable optimization for gcc x64 builds

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 wrote: >>> So my 1st question is why do you need to mix calling conventions, >>> and depend >>> on EFIAPI for interoperability. Why not just chang

Re: [edk2] [PATCH 1/3] KVM: MTRR: fix memory type handling if MTRR is completely disabled

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

Re: [edk2] [PATCH 1/3] KVM: MTRR: fix memory type handling if MTRR is completely disabled

On 16/07/2015 06:10, Alex Williamson wrote: > On Thu, 2015-07-16 at 03:25 +0800, Xiao Guangrong wrote: >> > From: Xiao Guangrong >> > >> > Currently code uses default memory type if MTRR is fully disabled, >> > fix it by using UC instead >> > >> > Signed-off-by: Xiao Guangrong >> > --- > Seem

Re: [edk2] [PATCH 3/3] KVM: x86: quirkily apply WB to all memory if cache is disabled

On 15/07/2015 21:25, Xiao Guangrong wrote: > From: Xiao Guangrong > > 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 using KVM_ENABLE

Re: [edk2] MTRR setup in OVMF [was: PATCH v3 01/10 KVM: MMU: fix decoding cache type from MTRR]

> 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 -

Re: [edk2] [PATCH V3 4/5] Add PCD for selecting terminal type at build time

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. >> >> Bu

Re: [edk2] [PATCH 00/21] OvmfPkg: support extra PCI root buses

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

Re: [edk2] Proposal of Git Repo Layout for EDKII project

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 ato

Re: [edk2] Proposal of Git Repo Layout for EDKII project

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:// >> github.com/tianocore >> ). There are EDKII project Repo and each >> package

Re: [edk2] update on SMM for OVMF

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 > - PcdCpuS3D

Re: [edk2] update on SMM for OVMF

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 i

Re: [edk2] update on SMM for OVMF

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

Re: [edk2] KVM Forum 2015 Call for Participation

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: Ca

Re: [edk2] implementing EFI_SMM_CONTROL2_PROTOCOL.Trigger()

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

Re: [edk2] implementing EFI_SMM_CONTROL2_PROTOCOL.Trigger()

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 > E

[edk2] KVM Forum 2015 Call for Participation

= 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 i

Re: [edk2] [PATCH 1/4] ArmVirtualizationPkg: build UEFI shell from source

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 s

Re: [edk2] Discussion about new mailing list host

On 08/03/2015 01:44, Jordan Justen wrote: > On 2015-03-07 09:08:05, Paolo Bonzini wrote: > > 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. &g

Re: [edk2] Discussion about new mailing list host

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

Re: [edk2] Local APIC's LINT0 / LINT1 Configuration

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 interru

Re: [edk2] [PATCH 2/3] OvmfPkg: factor out QemuLoaderLib from AcpiPlatformDxe

On 28/01/2015 00:29, Jordan Justen wrote: > They may be different, but looking, I'm wondering why > OvmfPkg/Library/QemuFwCfgLib doesn't have arm support, rather than > putting it into a separate module over in > ArmPlatformPkg/ArmVirtualizationPkg/Library/QemuFwCfgLib. > > It still may be valid

Re: [edk2] CirrusLogic5430 display card

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 teste

Re: [edk2] Possible problem with PciCf8Lib

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 PCI_CF8_LIB_ADDRESS(Bus,Dev

Re: [edk2] Possible problem with PciCf8Lib

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 PCI_CF8_LIB_ADDRESS(Bus,Dev

Re: [edk2] BaseTools and MdePkg ProcessorBind.h files

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 a

Re: [edk2] [PATCH 0/3] turn 'LUN encoding in CDB' into an explicit feature

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 Fea

Re: [edk2] [PATCH v7] OvmfPkg: PlatformBdsLib: Dynamic PCI Interrupt Line register setup

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 >>

Re: [edk2] [PATCH v4 6/6] OvmfPkg: PlatformBdsLib: Platform dependent PCI/IRQ initialization

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 supp

Re: [edk2] [PATCH v4 6/6] OvmfPkg: PlatformBdsLib: Platform dependent PCI/IRQ initialization

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 po

Re: [edk2] [PATCH v3 6/6] OvmfPkg: PlatformBdsLib: Platform dependent PCI/IRQ initialization

On 10/28/2014 01:53 PM, Gabriel Somlo wrote: > The device might always be present, but if we ever figure out how to > either re-enumerate the PCI bus, or have the already existing > enumeration logic populate some data structure we can later traverse, > we can get rid of *all* explicit PCI_LIB_AD

Re: [edk2] [PATCH v3 0/6] OVMF: Adding support for Qemu Q35 machine type

vailable on github > https://github.com/gsomlo/edk2 Reviewed-by: Paolo Bonzini (Note: Laszlo is on vacation this week). Paolo > Thanks, > Gabriel > >> This series removes hard-coded assumptions about the presence of a PIIX4 >> chipset, and dynamically probes for the

Re: [edk2] [PATCH v2 0/7] OVMF: Adding support for Qemu Q35 machine type

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, ho

Re: [edk2] [PATCH 0/7] OvmfPkg: PlatformBdsLib cleanups and improvements

>> 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

Re: [edk2] [PATCH 0/7] OvmfPkg: PlatformBdsLib cleanups and improvements

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 al

Re: [edk2] [PATCH 0/7] OvmfPkg: PlatformBdsLib cleanups and improvements

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 w

Re: [edk2] [PATCH 01/14] OvmfPkg: initialize Q35 platform

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

Re: [edk2] [PATCH 01/14] OvmfPkg: initialize Q35 platform

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, >>

Re: [edk2] [PATCH 2/2] OvmfPkg: Fix VS2005 build warnings

Il 24/09/2014 23:09, Jordan Justen ha scritto: > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Jordan Justen > --- > OvmfPkg/Library/LoadLinuxLib/Linux.c| 6 +++--- > OvmfPkg/PlatformPei/MemDetect.c | 2 +- > OvmfPkg/QemuFlash

Re: [edk2] [PATCH 01/14] OvmfPkg: initialize Q35 platform

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:

Re: [edk2] OVMF, Q35 and USB keyboard/mouse

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); //

Re: [edk2] [Qemu-devel] [INVITE] OVMF BoF session at the KVM Forum 2014

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

Re: [edk2] [PATCH 2/2] MdeModulePkg: CoreStall: improve accuracy in iterating branch

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); >> +

Re: [edk2] [PATCH 2/2] MdeModulePkg: CoreStall: improve accuracy in iterating branch

Il 14/09/2014 15:06, Laszlo Ersek ha scritto: > + } else { > +Accumulator -= gMetronome->TickPeriod; > +if (Counter == MAX_UINT64) { > + CoreInternalWaitForTick (Counter); > + CoreInternalWaitForTick (1); > +} else { > + CoreInternalWaitForTic

Re: [edk2] OVMF, Q35 and USB keyboard/mouse

Il 12/09/2014 20:18, Gabriel L. Somlo ha scritto: >> > Now *that* is really strange, especially as UHCI1 is pci function 0, >> > without probing that successfully you wouldn't see the other pci >> > functions (1+2+7 for uhci2+uhci3+ehci) in the same slot in the first >> > place. > I've only ever sk

Re: [edk2] OVMF, Q35 and USB keyboard/mouse

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

Re: [edk2] OVMF, Q35 and USB keyboard/mouse

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

Re: [edk2] OVMF, Q35 and USB keyboard/mouse

Il 11/09/2014 17:42, Gabriel L. Somlo ha scritto: > Building SeaBIOS w/o EHCI and UHCI won't allow me to type into > Chameleon's boot prompt at all (and yes, I do end up getting the > "usb-kbd: warning: key event queue full" errors after a few > keystrokes). Can you configure Chamaleon to avoid th

Re: [edk2] OVMF, Q35 and USB keyboard/mouse

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 ich9-usb-uhci1,

Re: [edk2] [PATCH 4/4] OvmfPkg: AcpiPlatformDxe: implement QEMU's full ACPI table loader interface

> So the idea is, look at the target area, > - determine if the remaining size in that blob (the pointed-to blob) > could still contain an ACPI table header, > - if so, check the presumed "length" field in that header, and see if > it's self-consistent (ie. >= sizeof(header), and <= remaining

Re: [edk2] [PATCH] MdePkg BaseLib NASM Thunk16: Initialize _16GdtrBase to 0

bler and file bugs" 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 wrote: > >> Il 30/08/2014 08:47, Jordan Justen ha scritto: >>

Re: [edk2] [PATCH] MdePkg BaseLib NASM Thunk16: Initialize _16GdtrBase to 0

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

Re: [edk2] [PATCH 4/4] OvmfPkg: AcpiPlatformDxe: implement QEMU's full ACPI table loader interface

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 f

Re: [edk2] [PATCH 4/4] OvmfPkg: AcpiPlatformDxe: implement QEMU's full ACPI table loader interface

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 possi

Re: [edk2] [PATCH 2/2] MdeModulePkg: Check D2H register status in AhciPioTransfer

Il 13/08/2014 09:02, A. Sava ha scritto: > Sounds like situation with Marvell is similar to Qemu. > > As I wrote earlier in this thread, Qemu also doesn't use PIO Setup FIS, > it puts only D2H FIS at the end of a PIO command. That's why Reza > checked if there are other controllers that behave sim

Re: [edk2] [OVFM] Example usage of the BaseSerialPortLibIoPort OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf

Il 08/08/2014 00:49, Laszlo Ersek ha scritto: > - Will this redirection break the terminal driver, for example? OVMF > does make use of the serial port even when DEBUG() goes to the QEMU > debug port. For example, thanks to ConSplitterDxe, the setup screens > (Boot manager, Boot maintenance manager

Re: [edk2] license for binary drivers

Il 06/08/2014 23:51, Andrew Fish ha scritto: > On Aug 6, 2014, at 6:44 AM, Paolo Bonzini wrote: >> However, the non-free nature of the OVMF binaries mean that QEMU >> will never ever ship OVMF binaries until the license is fixed for >> the offending FAT driver. Not only bec

Re: [edk2] license for binary drivers

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.).

Re: [edk2] [PATCH v2 0/2] edksetup.sh: Improvements for out-of-tree BaseTools

Il 24/07/2014 21:27, Jordan Justen ha scritto: > You can add > Reviewed-by: Jordan Justen > 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 them to https://github

Re: [edk2] KVM Forum 2014 Call for Participation (reminder)

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 > > (

Re: [edk2] [PATCH] BuildEnv: remove useless check before setting $WORKSPACE

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

Re: [edk2] [PATCH v2 0/2] edksetup.sh: Improvements for out-of-tree BaseTools

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? Ind

Re: [edk2] [PATCH v2 0/2] edksetup.sh: Improvements for out-of-tree BaseTools

Il 27/06/2014 19:16, Jordan Justen ha scritto: > On Thu, Jun 26, 2014 at 2:33 PM, Paolo Bonzini 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 >>>>>

Re: [edk2] [PATCH v2 0/2] edksetup.sh: Improvements for out-of-tree BaseTools

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

Re: [edk2] [PATCH v2 0/2] edksetup.sh: Improvements for out-of-tree BaseTools

Il 25/06/2014 21:42, Jordan Justen ha scritto: > On Wed, Jun 25, 2014 at 12:10 PM, Paolo Bonzini wrote: >> Il 25/06/2014 20:52, Jordan Justen ha scritto: >> >>>>> The patches make it possible to separately package tools in /usr >>>>> and use them comp

Re: [edk2] [PATCH v2 1/2] edksetup.sh: Look for BuildEnv under EDK_TOOLS_PATH

K_TOOLS_PATH/BuildEnv 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,

Re: [edk2] [PATCH v2 0/2] edksetup.sh: Improvements for out-of-tree BaseTools

Il 25/06/2014 20:52, Jordan Justen ha scritto: >> > The patches make it possible to separately package tools in /usr >> > and use them compile EDK2. > How are you envisioning the packaging to work? I think that installing > all the edk2 BaseTools executables in /usr/bin would be silly. Why? That'

[edk2] [PATCH v2 1/2] edksetup.sh: Look for BuildEnv under EDK_TOOLS_PATH

because the build process for BaseTools and OVMF is completely different. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Laszlo Ersek Signed-off-by: Paolo Bonzini --- edksetup.sh | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/edksetup.sh b/edks

[edk2] [PATCH v2 0/2] edksetup.sh: Improvements for out-of-tree BaseTools

common mistakes are detected 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,

[edk2] [PATCH v2 2/2] edksetup.sh: Ensure that WORKSPACE points to the top of an edk2 checkout

ed-by: Laszlo Ersek Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini --- edksetup.sh | 46 -- 1 file changed, 44 insertions(+), 2 deletions(-) diff --git a/edksetup.sh b/edksetup.sh index 5b4d37e..a576d92 100755

Re: [edk2] [PATCH] Check that WORKSPACE points to the top of the edk2 checkout

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. :) > - m

[edk2] [PATCH] Check that WORKSPACE points to the top of the edk2 checkout

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 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini

Re: [edk2] Sync BaseTools Trunk (version r2669) to EDKII main trunk

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

Re: [edk2] [PATCH] BuildEnv: remove useless check before setting $WORKSPACE

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 -- a

[edk2] [PATCH] BuildEnv: remove useless check before setting $WORKSPACE

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 --- a/BaseTools/BuildEnv +++ b/BaseTools/BuildEnv @@ -23,14 +23,6

[edk2] [PATCH] Look for BuildEnv under EDK_TOOLS_PATH

tribution Agreement 1.0 Signed-off-by: Paolo Bonzini --- a/edksetup.sh +++ b/edksetup.sh @@ -35,11 +35,14 @@ function SetupEnv() { - if [ -z "$WORKSPACE" ] + if [ -n "$WORKSPACE" ] then -. BaseTools/BuildEnv $* - else . $WORKSPACE/BaseTools/Bu

[edk2] KVM Forum 2014 Call for Participation

= 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) =

Re: [edk2] Accessing I2C devices under OVMF

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

Re: [edk2] [PATCH] OvmfPkg: add a catch-all match for PCI devices in the OpenFirmware path

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

[edk2] [PATCH] OvmfPkg: add a catch-all match for PCI devices in the OpenFirmware path

Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini --- 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/QemuBootOrder.c

[edk2] [PATCH] OvmfPkg: non-null PcdLib instance for the CSM VideoDxe

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 Cc: Laszlo Ersek Signed-off-by: Paolo Bonzini --- OvmfPkg/OvmfPkgIa32.dsc

Re: [edk2] [PATCH v2 00/19] OvmfPkg: improve video mode selection

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

Re: [edk2] OVMF on QEMU with recent EDK2 code

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

Re: [edk2] OVMF on QEMU with recent EDK2 code

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

Re: [edk2] [virtio-comment] virtio-blk vs. caching on FVP Base

Il 23/01/2014 18:09, Laszlo Ersek ha scritto: > > They both worked in the sense that each got me over the immediate FVP > Base model warning, and *something* was loaded from the virtio-blk disk. > However that "something" (which should have been a grub2 binary) could > not be executed, implying tha

Re: [edk2] apparent KVM problem with LRET in TianoCore S3 resume trampoline

Il 06/12/2013 15:47, Yao, Jiewen ha scritto: > Good investigation. I really appreciate that. > > Now, it seems we need OVMF pkg owner to check when 0x9c000 are corrupted, and > why. FWIW it's 0x1000110, not 0x9c000. But everything else is right. Paolo -

Re: [edk2] apparent KVM problem with LRET in TianoCore S3 resume trampoline

Il 06/12/2013 14:46, Yao, Jiewen ha scritto: > Hi Paolo > I am a little confused here. You said "Still, indeed it's OVMF's fault." and > "Still an EDK2 problem." ?? Sorry for the confusion. I wrote OVMF/EDK2 interchangeably, just to say "not KVM". > EDKII BIOS should always create 1:1 mappi

Re: [edk2] apparent KVM problem with LRET in TianoCore S3 resume trampoline

Il 06/12/2013 13:03, Paolo Bonzini ha scritto: > The page tables are, ahem, crap: > > 000c000: 6750 fe01 gP.. > 000c010: > 000c020:

Re: [edk2] apparent KVM problem with LRET in TianoCore S3 resume trampoline

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 >>> unexpec

Re: [edk2] apparent KVM problem with LRET in TianoCore S3 resume trampoline

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(

Re: [edk2] [Qemu-devel] [qemu PATCH] hw/i386/pc_sysfw: support more than one flash drive

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 abou

Re: [edk2] [Qemu-devel] [qemu PATCH] hw/i386/pc_sysfw: support more than one flash drive

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 gues

Re: [edk2] [edk2 PATCH] OvmfPkg: split the variable store to a separate file

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

Re: [edk2] [edk2 PATCH] OvmfPkg: split the variable store to a separate file

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

Re: [edk2] [PATCH] exec: fix regression by making system-memory region UINT64_MAX size

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

Re: [edk2] [PATCH] exec: fix regression by making system-memory region UINT64_MAX size

Il 08/11/2013 11:44, Peter Maydell ha scritto: > On 8 November 2013 08:05, Paolo Bonzini wrote: >> Il 07/11/2013 22:51, Peter Maydell ha scritto: >>>>> 1. Not all architectures have the behavior: "Address space that is not >>>>> RAM(and friends) >&

[edk2] reverting commit a53ae8e934cd54686875b5bcfc2f434244ee55d6 Re: [PATCH 0/2] Re: exec: fix regression by making system-memory region UINT64_MAX size

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 > -000ff

Re: [edk2] [PATCH] exec: fix regression by making system-memory region UINT64_MAX size

Il 07/11/2013 22:51, Peter Maydell ha scritto: >> > 1. Not all architectures have the behavior: "Address space that is not >> > RAM(and friends) >> > is for sure PCI". Only x86 behaves like this (I think). > > More specifically, the x86 pc behaves like this. Other > x86 based systems could in

Re: [edk2] [PATCH] exec: fix regression by making system-memory region UINT64_MAX size

Il 07/11/2013 22:24, Marcel Apfelbaum ha scritto: > Thank you Laszlo for the detailed info! > I think the problem is right above. Why pci-hole and system.flash collide? > IMHO we should not play with priorities here, better solve the collision. We need to audit all the other boards that support PC

Re: [edk2] [Qemu-devel] [PATCH] exec: fix regression by making system-memory region UINT64_MAX size

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 >

  1   2   >