Re: [Xen-devel] [ipxe-devel] Tips on how to debug EFI code (iPXE) from within KVM after ipxe.efi has crashed with #GP?

[Laszlo Ersek]

On 09/28/17 20:04, Michael Brown wrote:
> On 28/09/17 18:37, Konrad Rzeszutek Wilk wrote:
>> !!! X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID -
>>  
>> ExceptionData - 
>> RIP  - BEC2949C, CS  - 0038, RFLAGS -
>> 00210216
>> 
>>  Find image 808610ed.efidrv (ImageBase=BEC27000,
>> EntryPoint=BEC2E089) 
>>
>> And now I am trying to figure out how to troubleshoot this.
>> (and yes I am thinking it was related to the Tivoli work-around, but
>> disabling that didn't help).
> 
> The Tivoli workaround is for legacy BIOS only; it doesn't apply to the
> UEFI build of iPXE.
> 
> You have the RIP and ImageBase, so you know that the exception happens
> at offset +0x249c within your iPXE binary.  You can use this in
> conjunction with the corresponding map file from the iPXE build (which
> will probably be named bin-x86_64-efi/808610d3.efidrv.tmp.map, but see
> below) to figure out exactly where the crash is occurring.

Or run "objdump -S 808610d3.efidrv.tmp", and look up the offset in the
output. (First, check if (EntryPoint - ImageBase), i.e., 0x7089, equals
"start address" in the "objdump -x" output.)

Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] [PATCH] Maintainers.txt: update OvmfPkg maintainership

[Laszlo Ersek]

Hello Konrad,

On 08/23/17 03:30, Konrad Rzeszutek Wilk wrote:
> On Thu, Aug 17, 2017 at 01:47:59AM +0200, Laszlo Ersek wrote:
>> On 08/17/17 00:37, Jordan Justen wrote:
>>> On 2017-08-16 12:23:49, Leif Lindholm wrote:
>>
>> [snip]
>>
>>>> - the value proposition
>>>> for Linaro is that having maintainer parity ArmVirtPkg/OvmfPkg
>>>> simplifies the task of maintaining feature parity between the two.
>>>> (It is no secret that I would love to see them as a single package,
>>>> making it easier to clean up the way EDK2-for-qemu gets packaged by
>>>> Linux distributions.)
>>>
>>> I would also prefer to have OVMF support ARM and eventually RISC-V as
>>> well. I don't think Laszlo feels as confident about this though.
>>
>> I have two concerns:
>>
>> (1) Reorganizing OvmfPkg for this would take an immense amount of time
>> (with possible regressions).
>>
>> (2) Sharing more code between modules that aren't inherently
>> architecture-independent (and virtualization platform-independent) is risky.
>>
>> By "sharing more code", I mean extracting further library classes and
>> then unifying originally separate drivers. I also mean extracting common
>> files from separate library instances, and then unifying the lib
>> instances in a common directory, with multiple INF files, or with
>> arch-dependent sections in the one resultant INF file. Another method is
>> to control the same set of drivers / library instances differently, via
>> dynamic PCDs.
>>
>> While all this is great for code de-duplication, the chance of
>> regressions skyrockets if the code de-dup is not matched by a similar
>> overlap in maintenance (that is, review and testing).
>>
>> Personally I use QEMU/KVM (and occasionally QEMU/TCG) on x86 and
>> aarch64. I don't use 32-bit ARM (even guests, on aarch64 hosts), or any
>> kind of Xen. I've never seen RISC-V hardware (and probably won't --
>> nested TCG with QEMU doesn't count).
>>
>> The best counter-indication for this kind of increased sharing is the
>> *numerous* Xen-related regressions that have slipped through in the
>> past, simply because none of the OvmfPkg maintainers use Xen. (And the
>> Xen project seems to be unwilling or unable to delegate an official
>> reviewer or co-maintainer for the Xen-related code in OvmfPkg, despite
>> my repeated requests.) This has happened under ArmVirtPkg too (I recall
> 
> Who did you email/speak to? I hadn't seen any emails sent by
> you to xen-devel mailing list, but perhaps I missed them?

These emails are not easy to find (even in my own mailbox) because my
calls for help / suggestions for co-maintenance have been scattered over
time, loosely tied to OVMF regressions on Xen, or new Xen features in OVMF.

Keyword searches didn't help much, but I managed to find this email, for
example:

http://mid.mail-archive.com/f5e03398-33ca-c90d-743f-691d927657d3@redhat.com

Anthony, Gary, and xen-devel were addressed (among others). On 09/08/16
12:24, I wrote:

> Now, if you create a new platform (DSC + FDF) for Xen, that sort of
> forces someone from the Xen community to assume co-maintainership for
> the Xen bits. (Hopefully those bits would be easily identifiable by
> pathname.) I'd welcome that *very much*.

I remember more (for example I distinctly remember inviting Gary), but I
can't locate that message now.

On 08/23/17 03:30, Konrad Rzeszutek Wilk wrote:
> It should be fairly simple to expand the 0-day OSSTest to build
> TianoCore and launch guests with it as a nice regression test.

The point is to catch regressions before they are merged. This requires
someone who uses Xen every day to review and/or test patches posted to
edk2-devel that affect Xen code in OVMF.

(If the OSSTest tool can identify and pick such patches from edk2-devel
automatically, that would work too, of course.)

Thanks,
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Is: Fix for 4MB BIOS payload in hvmloader. Was:Re: [edk2] [PATCH 0/5] OvmfPkg: complete the 4MB flash image support ("-bios" / emulated variables)

[Laszlo Ersek]

On 05/23/17 17:02, Julien Grall wrote:
> Hi,
> 
> On 23/05/17 15:12, Konrad Rzeszutek Wilk wrote:
 The primary location for reporting bugs against the hypervisor and
 associated bundled tools [...] is by posting to the xen-devel mailing
 list (list info). Please tag your subject line with a '[BUG]' prefix.
 Note that you do not need to be subscribed to the list to post
 (although non-subscribers are moderated this usually happens pretty
 quickly) and that list policy is to CC people so you shouldn't miss
 any replies.

 [...]

 Although a bugzilla instance does exist it is not well maintained or
 widely used by developers. If you really want to file a bug in
 bugzilla you are strongly recommended to also post to the mailing
 list.
>>>
>>> This does not make things easier for us, because rather than recurrently
>>> check a simple bug status field in the Xen tracker, we'd have to be
>>> tapped into Xen development, and follow the email thread & any relevant
>>> commits closely. In reality I'm not even subscribed to xen-devel.
> 
> We recently introduced a tracker ([1]) to help us following the state of
> bugs/features. It is managed by maintainers and read-only for the others.
> 
> The usual process is to report the bug on the mailing-list and a
> maintainer will create a bug on the tracker if we have no immediate
> solution.

That's perfect; we'll be able to reference Xen issue reports with URLs
like (just an example) ,
from TianoCore BZs. That should enable us to quickly re-check the state
of the Xen report whenever we revisit the dependent TianoCore BZ.

... Can you please add the information about "xenproject.atlassian.net"
to the Xen Wiki article at
?

> In this case, the patch made rc6. So I believe the problem is resolved.

Yes, it is. Thanks!
Laszlo

> Cheers,
> 
> [1] https://xenproject.atlassian.net/projects/XEN/issues
> 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Is: Fix for 4MB BIOS payload in hvmloader. Was:Re: [edk2] [PATCH 0/5] OvmfPkg: complete the 4MB flash image support ("-bios" / emulated variables)

[Laszlo Ersek]

On 05/23/17 17:01, Jan Beulich wrote:
>>>> On 23.05.17 at 16:12, <kon...@kernel.org> wrote:
>> On Thu, May 18, 2017 at 02:36:33PM +0200, Laszlo Ersek wrote:
>>> The situation is further hampered by the fact that Xen is (apparently)
>>> right at 4.9.0-rc5, so they likely won't commit Jan's hvmloader patch
>>> until Xen 4.9 is out. This is a problem for a potential TianoCore-side
>>> BZ because the delay will make us forget about the issue.
> 
> The patch went in in time for rc6.

Thank you Jan for the speedy fix!

While reviewing version 2 of this patch set, Jordan wrote in
<https://lists.01.org/pipermail/edk2-devel/2017-May/010776.html>:

> With the understanding that we're holding off on the final patch for
> now to coordinate with Xen:
>
> Series Reviewed-by: Jordan Justen 

"the final patch" referenced there was:

  [edk2] [PATCH v2 5/5] OvmfPkg: make the 4MB flash size the default
(again)
  https://lists.01.org/pipermail/edk2-devel/2017-May/010763.html

So I have now modified the commit message on that patch, adding the
following paragraph:

> Xen gained support for the 4MB flash image in Xen commit 0d6968635ce5
> ("hvmloader: avoid tests when they would clobber used memory",
> 2017-05-19), which is part of Xen 4.9.0-rc6.

Seeing Gary's Tested-by on the Xen commit, I've also pushed the reworded
edk2 patch, as commit 1c47fcd465a4.

Thanks!
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] [PATCH RFC 06/14] OvmfPkg/XenPlatformPei: Add xen PVH specific code

[Laszlo Ersek]

On 01/10/17 17:18, Anthony PERARD wrote:
> On Thu, Jan 05, 2017 at 11:30:32AM +0100, Laszlo Ersek wrote:
>> On 12/08/16 16:33, Anthony PERARD wrote:
>>> - learn about memory size from the E820
>>> - ignore error if host bridge devid is 0x, PVH does not have PCI and
>>>   reading from unexisting device return -1.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Anthony PERARD <anthony.per...@citrix.com>
>>> ---
>>>  OvmfPkg/XenPlatformPei/MemDetect.c | 71 
>>> ++
>>>  OvmfPkg/XenPlatformPei/Platform.c  |  5 +++
>>>  OvmfPkg/XenPlatformPei/Platform.h  | 10 ++
>>>  3 files changed, 86 insertions(+)
>>>
>>> diff --git a/OvmfPkg/XenPlatformPei/MemDetect.c 
>>> b/OvmfPkg/XenPlatformPei/MemDetect.c
>>> index 4ecdf5e..0d80775 100644
>>> --- a/OvmfPkg/XenPlatformPei/MemDetect.c
>>> +++ b/OvmfPkg/XenPlatformPei/MemDetect.c
>>> @@ -42,6 +42,70 @@ UINT8 mPhysMemAddressWidth;
>>>  STATIC UINT32 mS3AcpiReservedMemoryBase;
>>>  STATIC UINT32 mS3AcpiReservedMemorySize;
>>>  
>>> +STATIC UINT32 mXenLowerMemorySize = 0;
>>> +STATIC UINT64 mXenHighMemorySize = 0;
>>> +
>>> +VOID
>>> +XenReadMemorySizes (
>>> +  VOID
>>> +  )
>>> +{
>>> +  EFI_E820_ENTRY64  *E820Map;
>>> +  UINT32E820EntriesCount;
>>> +  EFI_STATUS Status;
>>> +
>>> +  Status = XenGetE820Map (, );
>>> +  ASSERT_EFI_ERROR (Status);
>>> +
>>> +  mXenLowerMemorySize = 0;
>>> +  mXenHighMemorySize = 0;
>>> +
>>> +  if (E820EntriesCount > 0) {
>>> +EFI_E820_ENTRY64 *Entry;
>>> +UINT32 Loop;
>>> +
>>> +for (Loop = 0; Loop < E820EntriesCount; Loop++) {
>>> +  Entry = E820Map + Loop;
>>> +
>>> +  //
>>> +  // Only care about RAM
>>> +  //
>>> +  if (Entry->Type != EfiAcpiAddressRangeMemory) {
>>> +continue;
>>> +  }
>>> +
>>> +  if ((Entry->BaseAddr + Entry->Length) <= SIZE_16MB) {
>>> +continue;
>>> +  }
>>> +
>>> +  if (Entry->BaseAddr < SIZE_16MB) {
>>> +UINT64 bottom = Entry->BaseAddr;
>>> +UINT64 size = Entry->Length;
>>> +size -= SIZE_16MB - bottom;
>>> +bottom = SIZE_16MB;
>>> +mXenLowerMemorySize += size;
>>> +continue;
>>> +  }
>>> +  if (Entry->BaseAddr <= SIZE_4GB) {
>>> +UINT64 size = Entry->Length;
>>> +mXenLowerMemorySize += size;
>>> +continue;
>>> +  }
>>> +
>>> +  if (Entry->BaseAddr == SIZE_4GB) {
>>> +mXenHighMemorySize = Entry->Length;
>>> +continue;
>>> +  }
>>> +
>>> +  DEBUG ((EFI_D_INFO, "%a: ignored XenE820 entry (0x%llx, 0x%llx)\n",
>>> +  __FUNCTION__,
>>> +  Entry->BaseAddr,
>>> +  Entry->Length));
>>> +}
>>> +mXenLowerMemorySize += SIZE_16MB;
>>> +  }
>>> +}
>>> +
>>>  UINT32
>>>  GetSystemMemorySizeBelow4gb (
>>>VOID
>>> @@ -50,6 +114,9 @@ GetSystemMemorySizeBelow4gb (
>>>UINT8 Cmos0x34;
>>>UINT8 Cmos0x35;
>>>  
>>> +  if (mXen && mXenLowerMemorySize)
>>> +return mXenLowerMemorySize;
>>> +
>>>//
>>>// CMOS 0x34/0x35 specifies the system memory above 16 MB.
>>>// * CMOS(0x35) is the high byte
>>> @@ -74,6 +141,10 @@ GetSystemMemorySizeAbove4gb (
>>>UINT32 Size;
>>>UINTN  CmosIndex;
>>>  
>>> +  // if lower memory is specified that way, return also high memory
>>> +  if (mXen && mXenLowerMemorySize)
>>> +return mXenHighMemorySize;
>>> +
>>>//
>>>// CMOS 0x5b-0x5d specifies the system memory above 4GB MB.
>>>// * CMOS(0x5d) is the most significant size byte
>>> diff --git a/OvmfPkg/XenPlatformPei/Platform.c 
>>> b/OvmfPkg/XenPlatformPei/Platform.c
>>> index bf78878..9fc713c 100644
>>> --- a/OvmfPkg/XenPlatformPei/Platform.c
>>> +++ b/OvmfPkg/XenPlatformPei/Platform.c
>>> @@ -362,6 +362,10 @@ MiscInitialization (
>>>AcpiCtlReg = POWER_MGMT_REGISTER_Q35 (I

Re: [Xen-devel] [edk2] [PATCH RFC 14/14] XenOvmf: Use a different RTC

[Laszlo Ersek]

On 12/08/16 16:33, Anthony PERARD wrote:
> ---
>  OvmfPkg/XenOvmf.dsc | 5 -
>  OvmfPkg/XenOvmf.fdf | 2 +-
>  2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index a7a884e..345157b 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -567,7 +567,10 @@
>}
>MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
>MdeModulePkg/Universal/Metronome/Metronome.inf
> -  PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
> +  EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf {
> +
> +  
> RealTimeClockLib|ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
> +  }
>MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
>  
> diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
> index a500ab6..65db2ba 100644
> --- a/OvmfPkg/XenOvmf.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -217,7 +217,7 @@ INF  
> MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
>  INF  MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
>  INF  MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
>  INF  MdeModulePkg/Universal/Metronome/Metronome.inf
> -INF  
> PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
> +INF  EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
>  
>  INF  OvmfPkg/BlockMmioToBlockIoDxe/BlockIo.inf
>  INF  OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
> 

(1) The subject should be

  OvmfPkg/XenOvmf: use RealTimeClockRuntimeDxe from EmbeddedPkg

or similar.

(2) By tradition, ArmVirtPkg is welcome to consume modules from OvmfPkg,
but not the other way around. If you need

  ArmVirtPkg/Library/XenRealTimeClockLib

in an OvmfPkg platform, please move the library instance first to
OvmfPkg, redirecting the ArmVirtPkg references, and then consume the
library in OvmfPkg, internally to OvmfPkg.

Thanks
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] [PATCH RFC 13/14] OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables

[Laszlo Ersek]

On 12/08/16 16:33, Anthony PERARD wrote:
> This "device" use XenIoMmioLib to reserve some space to be use by grant
> tables. It's use 0xfc00, which might not be a good choice...
> 
> There is probably a better way that using a device for this.
> ---
>  OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c   | 263 
> 
>  OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf |  45 ++
>  OvmfPkg/XenOvmf.dsc |   2 +
>  OvmfPkg/XenOvmf.fdf |   1 +
>  4 files changed, 311 insertions(+)
>  create mode 100644 OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
>  create mode 100644 OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf

I recommend to check out the existent use of XenIoMmioLib, namely in
"ArmVirtPkg/XenioFdtDxe".

In brief, for such purposes a DXE_DRIVER is appropriate, where you
simply do the deed (call XenIoMmioInstall()) in the driver's entry point
function. No need for a UEFI_DRIVER module which conforms to the UEFI
Driver Model.

Regarding where to put the area: no clue. If it doesn't overlap any
memory area added in (Xen)PlatformPei with memory resource descriptors,
nor areas added later in DXE, with gDS->AddMemorySpace(), then it should
be fine.

From a quick look, 0xFC00 should work. For completeness, I'd also
modify the (DXE) driver to call gDS->AddMemorySpace() with type
EfiGcdMemoryTypeReserved, and also immediately call
gDS->AllocateMemorySpace() with the same type and EfiGcdAllocateAddress,
in order to allocate the exact reserved chunk.

(See "7.2 Global Coherency Domain Services" in vol2 of the Platform Init
spec for background.)

OTOH, I don't see why a simple AllocateReservedPages() call wouldn't
work (which would carve a chunk out of normal system memory for this).
Why did you comment that out in the code below?

Also, please don't forget the Citrix copyright notice etc etc.

Thanks
Laszlo

> 
> diff --git a/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c 
> b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
> new file mode 100644
> index 000..12e076f
> --- /dev/null
> +++ b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
> @@ -0,0 +1,263 @@
> +/** @file
> +
> +  XXX
> +
> +  XXX
> +
> +  This program and the accompanying materials are licensed and made available
> +  under the terms and conditions of the BSD License which accompanies this
> +  distribution. The full text of the license may be found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
> WITHOUT
> +  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* #include  */
> +STATIC BOOLEAN mXenIoInitialized = FALSE;
> +
> +/**
> +
> +  Device probe function for this driver.
> +
> +  The DXE core calls this function for any given device in order to see if 
> the
> +  driver can drive the device.
> +
> +  @param[in]  ThisThe EFI_DRIVER_BINDING_PROTOCOL object
> +  incorporating this driver (independently of
> +  any device).
> +
> +  @param[in] DeviceHandle The device to probe.
> +
> +  @param[in] RemainingDevicePath  Relevant only for bus drivers, ignored.
> +
> +
> +  @retval EFI_SUCCESS  The driver supports the device being probed.
> +
> +  @retval EFI_UNSUPPORTED  The driver does not support the device being 
> probed.
> +
> +  @return  Error codes from the OpenProtocol() boot service 
> or
> +   the PciIo protocol.
> +
> +**/
> +#if 1
> +STATIC
> +EFI_STATUS
> +EFIAPI
> +XenIoPvhDeviceBindingSupported (
> +  IN EFI_DRIVER_BINDING_PROTOCOL *This,
> +  IN EFI_HANDLE  DeviceHandle,
> +  IN EFI_DEVICE_PATH_PROTOCOL*RemainingDevicePath
> +  )
> +{
> +
> +  // XXX check if running Xen PVH
> +  //
> +
> +  if (mXenIoInitialized) {
> +return EFI_ALREADY_STARTED;
> +  }
> +
> +  DEBUG((EFI_D_INFO, "%a %d\n", __FUNCTION__, __LINE__));
> +  return EFI_SUCCESS;
> +}
> +#endif
> +
> +/**
> +
> +  After we've pronounced support for a specific device in
> +  DriverBindingSupported(), we start managing said device (passed in by the
> +  Driver Execution Environment) with the following service.
> +
> +  See DriverBindingSupported() for specification references.
> +
> +  @param[in]  ThisThe EFI_DRIVER_BINDING_PROTOCOL object
> +  incorporating this driver (independently of
> +  any device).
> +
> +  @param[in] DeviceHandle The supported device to drive.
> +
> +  @param[in] RemainingDevicePath  Relevant only for bus drivers, ignored.
> +
> +
> +  @retval EFI_SUCCESS   The device was started.
> +
> +  @retval EFI_OUT_OF_RESOURCES  Memory allocation failed.
> +
> +  @return   Error codes from the OpenProtocol() boot
> +service, the PciIo protocol or the
> +

Re: [Xen-devel] [edk2] [PATCH RFC 12/14] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn

[Laszlo Ersek]

On 12/08/16 16:33, Anthony PERARD wrote:
> and add OvmfPkg/XenConsoleIo/XenConsoleIo to XenOvmf platform.
> 
> It actually look for gEfiSerialIoProtocolGuid.
> ---
>  .../Library/PlatformBootManagerLib/BdsPlatform.c   | 33 
> ++
>  .../PlatformBootManagerLib.inf |  2 ++
>  OvmfPkg/XenOvmf.dsc|  4 +++
>  OvmfPkg/XenOvmf.fdf|  1 +
>  4 files changed, 40 insertions(+)
> 
> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
> b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> index bd64cc3..b8972f7 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> @@ -904,6 +904,31 @@ DetectAndPreparePlatformPciDevicePaths (
>return VisitAllPciInstances (DetectAndPreparePlatformPciDevicePath);
>  }
>  
> +#include 
> +EFI_STATUS
> +EFIAPI
> +add_serial (
> +  IN EFI_HANDLE  DeviceHandle,
> +  IN VOID*Instance,
> +  IN VOID*Context
> +  )
> +{
> +  EFI_DEVICE_PATH_PROTOCOL  *DevicePath = NULL;
> +
> +  DevicePath = DevicePathFromHandle(DeviceHandle);
> +  if (DevicePath == NULL) {
> +return EFI_NOT_FOUND;
> +  }
> +
> +  DevicePath = AppendDevicePathNode (DevicePath, (EFI_DEVICE_PATH_PROTOCOL 
> *));
> +  DEBUG((EFI_D_ERROR, "%a %d: full path: %s\n", __FUNCTION__, __LINE__,
> + ConvertDevicePathToText(DevicePath, TRUE, FALSE)
> + ));
> +  EfiBootManagerUpdateConsoleVariable (ConOut, DevicePath, NULL);
> +  EfiBootManagerUpdateConsoleVariable (ConIn, DevicePath, NULL);
> +  EfiBootManagerUpdateConsoleVariable (ErrOut, DevicePath, NULL);
> +  return EFI_SUCCESS;
> +}
>  
>  VOID
>  PlatformInitializeConsole (
> @@ -931,6 +956,14 @@ Arguments:
>GetEfiGlobalVariable2 (EFI_CON_OUT_VARIABLE_NAME, (VOID **) , 
> NULL);
>GetEfiGlobalVariable2 (EFI_CON_IN_VARIABLE_NAME, (VOID **) , 
> NULL);
>  
> +  // do xen console
> +  //VISIT_PCI_INSTANCE_CALLBACK CallBackFunction
> +  VisitAllInstancesOfProtocol (
> +   ,
> +   add_serial,
> +   (VOID*)NULL
> +   );
> +
>if (VarConout == NULL || VarConin == NULL) {
>  //
>  // Do platform specific PCI Device check and add them to ConOut, ConIn, 
> ErrOut
> diff --git 
> a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
> b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> index 4a6bece..74ab6b1 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> @@ -73,6 +73,8 @@
>gEfiLoadedImageProtocolGuid   # PROTOCOL SOMETIMES_PRODUCED
>gEfiFirmwareVolume2ProtocolGuid   # PROTOCOL SOMETIMES_CONSUMED
>  
> +  gEfiSerialIoProtocolGuid
> +
>  [Guids]
>gEfiXenInfoGuid
>gEfiEndOfDxeEventGroupGuid
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index 31a2185..8bce996 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -590,6 +590,10 @@
>OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
>OvmfPkg/XenBusDxe/XenBusDxe.inf
>OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> +  OvmfPkg/XenConsoleIo/XenConsoleIo.inf {
> +
> +  
> SerialPortLib|OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf
> +  }
>MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
>
> MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
>MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
> diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
> index f6876d7..a40d186 100644
> --- a/OvmfPkg/XenOvmf.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -223,6 +223,7 @@ INF  OvmfPkg/BlockMmioToBlockIoDxe/BlockIo.inf
>  INF  OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
>  INF  OvmfPkg/XenBusDxe/XenBusDxe.inf
>  INF  OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> +INF  OvmfPkg/XenConsoleIo/XenConsoleIo.inf
>  
>  !if $(SECURE_BOOT_ENABLE) == TRUE
>INF  
> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
> 

Okay, so this patch forced me to review the current additions of serial
port devpaths to ConIn, ConOut, ErrOut in

  OvmfPkg/Library/PlatformBootManagerLib/

I think I understand what you intend to do. I'd like to propose an
alternative I feel would be better.

You are introducing a new driver called "XenConsoleIo" which I assume is
a DXE_DRIVER module that produces gEfiSerialIoProtocolGuid. The reason I
can only "assume" is that you apparently forgot to include the driver in
the patch, with "git add". Nonetheless, without having seen the driver,
I claim that it should be unnecessary.

Namely, MdeModulePkg provides a generic platform serial driver, under

  MdeModulePkg/Universal/SerialDxe/SerialDxe.inf

This driver is already used in the ARM Xen guest platform:

  ArmVirtPkg/ArmVirtXen.dsc

with a dependency on

  OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf

Re: [Xen-devel] [edk2] [PATCH RFC 11/14] OvmfPkg/XenOvmf: Adding XenTimerLocalApic

[Laszlo Ersek]

On 12/08/16 16:33, Anthony PERARD wrote:
> And replacing the ACPI Timer by this one based on the local APIC.
> 
> ACPI Timer does not work in a PVH guest, but local APIC works on both
> PVH and HVM.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Anthony PERARD 
> ---
>  OvmfPkg/XenOvmf.dsc |  18 +-
>  OvmfPkg/XenOvmf.fdf |   2 +-
>  OvmfPkg/XenTimerLocalApic/Timer.h   | 191 
>  OvmfPkg/XenTimerLocalApic/XenTimerLocalApic.c   | 386 
> 
>  OvmfPkg/XenTimerLocalApic/XenTimerLocalApic.inf |  51 
>  5 files changed, 640 insertions(+), 8 deletions(-)
>  create mode 100644 OvmfPkg/XenTimerLocalApic/Timer.h
>  create mode 100644 OvmfPkg/XenTimerLocalApic/XenTimerLocalApic.c
>  create mode 100644 OvmfPkg/XenTimerLocalApic/XenTimerLocalApic.inf

comments below:

> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index ef32c33..31a2185 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -81,7 +81,7 @@
>  
> 
>  [LibraryClasses]
>PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
> -  TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf
> +  TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
>PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
>BaseMemoryLib|MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf
>BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
> @@ -175,7 +175,7 @@
>  !endif
>  
>  [LibraryClasses.common.SEC]
> -  TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
> +  TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
>QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf
>  !ifdef $(DEBUG_ON_SERIAL_PORT)
>DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> @@ -251,7 +251,7 @@
>  
>  [LibraryClasses.common.DXE_RUNTIME_DRIVER]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> -  TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
> +  TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
>HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
>DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
>
> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
> @@ -269,7 +269,7 @@
>  
>  [LibraryClasses.common.UEFI_DRIVER]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> -  TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
> +  TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
>HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
>DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
>
> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
> @@ -284,7 +284,7 @@
>  
>  [LibraryClasses.common.DXE_DRIVER]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> -  TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
> +  TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
>HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
>
> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
>
> ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
> @@ -314,7 +314,7 @@
>  
>  [LibraryClasses.common.UEFI_APPLICATION]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> -  TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
> +  TimerLib|MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
>HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
>
> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
>
> ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf

(1) I suggest to split this patch if possible. In the first half, the
TimerLib class resolutions should be flipped, with the argument given in
the second paragraph of the commit message.

The subject line for the first patch should be something like

  OvmfPkg/XenOvmf: use a TimerLib instance that depends only on the CPU

> @@ -546,7 +546,11 @@
>  !endif
>  
>MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
> -  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> +  OvmfPkg/XenTimerLocalApic/XenTimerLocalApic.inf

(2) The second patch should introduce the new DXE_DRIVER module:

  OvmfPkg/XenOvmf: introduce XenTimerDxe

The commit message should document that
"PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf" is replaced with a
Xen-specific EFI_TIMER_ARCH_PROTOCOL implementation.

(3) The new DXE_DRIVER module should be located under "OvmfPkg/XenTimerDxe".

> +  #{
> +  #
> +
> #LocalApicLib|UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf
> +  #}

(4) Please don't just comment out unnecessary stuff; it's better to
remove 

Re: [Xen-devel] [edk2] [PATCH RFC 09/14] OvmfPkg/ResetSystemLib: Add missing dependency on PciLib

[Laszlo Ersek]

On 12/08/16 16:33, Anthony PERARD wrote:
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Anthony PERARD 
> ---
>  OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf 
> b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
> index ecd462b..2e0ed48 100644
> --- a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
> +++ b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
> @@ -36,4 +36,5 @@
>  [LibraryClasses]
>DebugLib
>IoLib
> +  PciLib
>TimerLib
> 

Please also #include  in "ResetSystemLib.c", for
consistency with the now-modified INF file.

(The lack of the #include directive is currently masked by the fact that
"OvmfPlatforms.h" includes "PciLib.h" too -- it needs PCI_LIB_ADDRESS().)

Also... not sure why, but we include "OvmfPlatforms.h" twice in
"ResetSystemLib.c". Can you please kill the second #include? Can be in
the same patch.

(Hm, it looks like the duplicate #include is my fault, an oversight from
commit 1466b76f9385.)

Thanks!
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] [PATCH RFC 08/14] OvmfPkg/PlatformBootManagerLib: Workaround missing PCI bus on Xen PVH

[Laszlo Ersek]

On 12/08/16 16:33, Anthony PERARD wrote:
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Anthony PERARD 
> ---
>  OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
> b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> index cc35630..bd64cc3 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> @@ -1152,6 +1152,8 @@ PciAcpiInitialization (
>PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6a), 0x0b); // G
>PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6b), 0x0b); // H
>break;
> +case 0x:
> +  return;
>  default:
>DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
>  __FUNCTION__, mHostBridgeDevId));
> 

Seems okay, but please use a new macro I mentined under patch 06/14. The
new macro name should contain the words XEN and PVH, preferably.

Thanks
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] [PATCH RFC 07/14] OvmfPkg/XenResetVector: Add new entry point for Xen PVH

[Laszlo Ersek]

On 12/08/16 16:33, Anthony PERARD wrote:
> This one enter directly in 32bits
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Anthony PERARD 
> ---
>  OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm | 79 
> +
>  OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm  | 23 +++
>  OvmfPkg/XenResetVector/XenResetVector.nasmb |  1 +
>  3 files changed, 103 insertions(+)
>  create mode 100644 OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
>  create mode 100644 OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm

(1) The new file "XenPVHMain.asm" is missing a license block (incl. a
Citrix copyright notice).

(2) You might want to add a similar (C) to the other new file,
"ResetVectorVtf0.asm", as well.

Thanks
Laszlo

> diff --git a/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm 
> b/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
> new file mode 100644
> index 000..70436d8
> --- /dev/null
> +++ b/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
> @@ -0,0 +1,79 @@
> +;--
> +; @file
> +; First code executed by processor after resetting.
> +;
> +; Copyright (c) 2008 - 2014, Intel Corporation. All rights reserved.
> +; This program and the accompanying materials
> +; are licensed and made available under the terms and conditions of the BSD 
> License
> +; which accompanies this distribution.  The full text of the license may be 
> found at
> +; http://opensource.org/licenses/bsd-license.php
> +;
> +; THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +; WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +;
> +;--
> +
> +BITS16
> +
> +ALIGN   16
> +
> +;
> +; Pad the image size to 4k when page tables are in VTF0
> +;
> +; If the VTF0 image has page tables built in, then we need to make
> +; sure the end of VTF0 is 4k above where the page tables end.
> +;
> +; This is required so the page tables will be 4k aligned when VTF0 is
> +; located just below 0x1 (4GB) in the firmware device.
> +;
> +%ifdef ALIGN_TOP_TO_4K_FOR_PAGING
> +TIMES (0x1000 - ($ - EndOfPageTables) - (fourGigabytes - 
> xenPVHEntryPoint)) DB 0
> +%endif
> +
> +BITS32
> +xenPVHEntryPoint:
> +; this is probably 0xffd0
> +  jmp xenPVHMain
> +
> +BITS16
> +ALIGN   16
> +
> +applicationProcessorEntryPoint:
> +;
> +; Application Processors entry point
> +;
> +; GenFv generates code aligned on a 4k boundary which will jump to this
> +; location.  (0xffe0)  This allows the Local APIC Startup IPI to be
> +; used to wake up the application processors.
> +;
> +jmp EarlyApInitReal16
> +
> +ALIGN   8
> +
> +DD  0
> +
> +;
> +; The VTF signature
> +;
> +; VTF-0 means that the VTF (Volume Top File) code does not require
> +; any fixups.
> +;
> +vtfSignature:
> +DB  'V', 'T', 'F', 0
> +
> +ALIGN   16
> +
> +resetVector:
> +;
> +; Reset Vector
> +;
> +; This is where the processor will begin execution
> +;
> +nop
> +nop
> +jmp EarlyBspInitReal16
> +
> +ALIGN   16
> +
> +fourGigabytes:
> +
> diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm 
> b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> new file mode 100644
> index 000..eb12f6c
> --- /dev/null
> +++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> @@ -0,0 +1,23 @@
> +BITS 32
> +
> +xenPVHMain:
> +  mov di, 'BP'
> +
> +  cli
> +  mov ebx, ADDR_OF(gdtr)
> +  lgdt [ebx]
> +  mov eax, SEC_DEFAULT_CR0
> +  mov cr0, eax
> +  jmp LINEAR_CODE_SEL:ADDR_OF(jmpHerePVH)
> +jmpHerePVH:
> +  mov eax, SEC_DEFAULT_CR4
> +  mov cr4, eax
> +
> +  mov ax, LINEAR_SEL
> +  mov ds, ax
> +  mov es, ax
> +  mov fs, ax
> +  mov gs, ax
> +  mov ss, ax
> +
> +  OneTimeCallRet TransitionFromReal16To32BitFlat
> diff --git a/OvmfPkg/XenResetVector/XenResetVector.nasmb 
> b/OvmfPkg/XenResetVector/XenResetVector.nasmb
> index 31ac06a..f9812fd 100644
> --- a/OvmfPkg/XenResetVector/XenResetVector.nasmb
> +++ b/OvmfPkg/XenResetVector/XenResetVector.nasmb
> @@ -61,6 +61,7 @@
>  %include "Ia16/Init16.asm"
>  
>  %include "Main.asm"
> +%include "Ia32/XenPVHMain.asm"
>  
>  %include "Ia16/ResetVectorVtf0.asm"
>  
> 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] [PATCH RFC 06/14] OvmfPkg/XenPlatformPei: Add xen PVH specific code

[Laszlo Ersek]

On 12/08/16 16:33, Anthony PERARD wrote:
> - learn about memory size from the E820
> - ignore error if host bridge devid is 0x, PVH does not have PCI and
>   reading from unexisting device return -1.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Anthony PERARD 
> ---
>  OvmfPkg/XenPlatformPei/MemDetect.c | 71 
> ++
>  OvmfPkg/XenPlatformPei/Platform.c  |  5 +++
>  OvmfPkg/XenPlatformPei/Platform.h  | 10 ++
>  3 files changed, 86 insertions(+)
> 
> diff --git a/OvmfPkg/XenPlatformPei/MemDetect.c 
> b/OvmfPkg/XenPlatformPei/MemDetect.c
> index 4ecdf5e..0d80775 100644
> --- a/OvmfPkg/XenPlatformPei/MemDetect.c
> +++ b/OvmfPkg/XenPlatformPei/MemDetect.c
> @@ -42,6 +42,70 @@ UINT8 mPhysMemAddressWidth;
>  STATIC UINT32 mS3AcpiReservedMemoryBase;
>  STATIC UINT32 mS3AcpiReservedMemorySize;
>  
> +STATIC UINT32 mXenLowerMemorySize = 0;
> +STATIC UINT64 mXenHighMemorySize = 0;
> +
> +VOID
> +XenReadMemorySizes (
> +  VOID
> +  )
> +{
> +  EFI_E820_ENTRY64  *E820Map;
> +  UINT32E820EntriesCount;
> +  EFI_STATUS Status;
> +
> +  Status = XenGetE820Map (, );
> +  ASSERT_EFI_ERROR (Status);
> +
> +  mXenLowerMemorySize = 0;
> +  mXenHighMemorySize = 0;
> +
> +  if (E820EntriesCount > 0) {
> +EFI_E820_ENTRY64 *Entry;
> +UINT32 Loop;
> +
> +for (Loop = 0; Loop < E820EntriesCount; Loop++) {
> +  Entry = E820Map + Loop;
> +
> +  //
> +  // Only care about RAM
> +  //
> +  if (Entry->Type != EfiAcpiAddressRangeMemory) {
> +continue;
> +  }
> +
> +  if ((Entry->BaseAddr + Entry->Length) <= SIZE_16MB) {
> +continue;
> +  }
> +
> +  if (Entry->BaseAddr < SIZE_16MB) {
> +UINT64 bottom = Entry->BaseAddr;
> +UINT64 size = Entry->Length;
> +size -= SIZE_16MB - bottom;
> +bottom = SIZE_16MB;
> +mXenLowerMemorySize += size;
> +continue;
> +  }
> +  if (Entry->BaseAddr <= SIZE_4GB) {
> +UINT64 size = Entry->Length;
> +mXenLowerMemorySize += size;
> +continue;
> +  }
> +
> +  if (Entry->BaseAddr == SIZE_4GB) {
> +mXenHighMemorySize = Entry->Length;
> +continue;
> +  }
> +
> +  DEBUG ((EFI_D_INFO, "%a: ignored XenE820 entry (0x%llx, 0x%llx)\n",
> +  __FUNCTION__,
> +  Entry->BaseAddr,
> +  Entry->Length));
> +}
> +mXenLowerMemorySize += SIZE_16MB;
> +  }
> +}
> +
>  UINT32
>  GetSystemMemorySizeBelow4gb (
>VOID
> @@ -50,6 +114,9 @@ GetSystemMemorySizeBelow4gb (
>UINT8 Cmos0x34;
>UINT8 Cmos0x35;
>  
> +  if (mXen && mXenLowerMemorySize)
> +return mXenLowerMemorySize;
> +
>//
>// CMOS 0x34/0x35 specifies the system memory above 16 MB.
>// * CMOS(0x35) is the high byte
> @@ -74,6 +141,10 @@ GetSystemMemorySizeAbove4gb (
>UINT32 Size;
>UINTN  CmosIndex;
>  
> +  // if lower memory is specified that way, return also high memory
> +  if (mXen && mXenLowerMemorySize)
> +return mXenHighMemorySize;
> +
>//
>// CMOS 0x5b-0x5d specifies the system memory above 4GB MB.
>// * CMOS(0x5d) is the most significant size byte
> diff --git a/OvmfPkg/XenPlatformPei/Platform.c 
> b/OvmfPkg/XenPlatformPei/Platform.c
> index bf78878..9fc713c 100644
> --- a/OvmfPkg/XenPlatformPei/Platform.c
> +++ b/OvmfPkg/XenPlatformPei/Platform.c
> @@ -362,6 +362,10 @@ MiscInitialization (
>AcpiCtlReg = POWER_MGMT_REGISTER_Q35 (ICH9_ACPI_CNTL);
>AcpiEnBit  = ICH9_ACPI_CNTL_ACPI_EN;
>break;
> +case 0x:
> +  // xen PVH, ignore
> +  PcdStatus = PcdSet16S (PcdOvmfHostBridgePciDevId, mHostBridgeDevId);
> +  return;

Can we create a new macro for 0x in
"OvmfPkg/Include/OvmfPlatforms.h", and use that here?

Normally I would suggest a separate header file under "OvmfPkg/Include",
similar to "Q35MchIch9.h" and "I440FxPiix4.h", and to include that new
file in "OvmfPlatforms.h", but here we only need a single "chipset
identifier", so I guess that can go directly into "OvmfPlatforms.h".

I mainly suggest this because in patch 08/14, the same 0x case label
is being added to code shared with QEMU, and using a verbose macro there
is much better than a magic number. In turn, we should use the same
macro here, I think.

Looks OK otherwise.

Thanks
Laszlo

>  default:
>DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
>  __FUNCTION__, mHostBridgeDevId));
> @@ -503,6 +507,7 @@ InitializeXenPlatform (
>DebugDumpCmos ();
>  
>XenDetect ();
> +  XenReadMemorySizes ();
>  
>BootModeInitialization ();
>AddressWidthInitialization ();
> diff --git a/OvmfPkg/XenPlatformPei/Platform.h 
> b/OvmfPkg/XenPlatformPei/Platform.h
> index eda765b..2948853 100644
> --- a/OvmfPkg/XenPlatformPei/Platform.h
> +++ b/OvmfPkg/XenPlatformPei/Platform.h
> @@ -101,4 +101,14 @@ extern BOOLEAN mS3Supported;
>  
>  extern UINT8 

Re: [Xen-devel] [edk2] [PATCH RFC 05/14] OvmfPkg/Library: add XenPciHostBridgeLib

[Laszlo Ersek]

On 12/08/16 16:33, Anthony PERARD wrote:
> A copy of OvmfPkg/Library/PciHostBridgeLib
> 
> Removing support for pci bus enumeration, I think, and only use scan of
> already enumerated pci bus.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Anthony PERARD 
> ---
>  .../Library/XenPciHostBridgeLib/XenPciHostBridge.h |  75 
>  .../XenPciHostBridgeLib/XenPciHostBridgeLib.c  | 291 +
>  .../XenPciHostBridgeLib/XenPciHostBridgeLib.inf|  58 +++
>  OvmfPkg/Library/XenPciHostBridgeLib/XenSupport.c   | 456 
> +
>  4 files changed, 880 insertions(+)
>  create mode 100644 OvmfPkg/Library/XenPciHostBridgeLib/XenPciHostBridge.h
>  create mode 100644 OvmfPkg/Library/XenPciHostBridgeLib/XenPciHostBridgeLib.c
>  create mode 100644 
> OvmfPkg/Library/XenPciHostBridgeLib/XenPciHostBridgeLib.inf
>  create mode 100644 OvmfPkg/Library/XenPciHostBridgeLib/XenSupport.c

(1) I think the following subject line is more idiomatic:

  OvmfPkg: add XenPciHostBridgeLib

Then, I'll practically repeat my comments for the previous patch:

(2) You might want to add Citrix copyright notices to new files.

(3) The Xen-related code that remains in the original PciHostBridgeLib
instance should be possible to remove later; if that's the case, can you
please write a subsequent patch for that too?

(4) The removed functionality should be named more precisely in the
commit message:

- PciHostBridgeGetRootBridges(): the search for extra PCI root buses
(which come from QEMU's pxb and pxb-pcie devices) is removed (hence the
"etc/extra-pci-roots" fw_cfg file is no longer consulted either, which
is otherwise used to speed up the search).

The Xen-specific ScanForRootBridges() function call is hardwired.

(5) It would be nice to hint at the reason (which is implemented in a
later patch) why a separate module is a good idea here. That is, why the
expected PVH2 functionality is best not added to the current
PciHostBridgeLib instance.

More below:

> diff --git a/OvmfPkg/Library/XenPciHostBridgeLib/XenPciHostBridge.h 
> b/OvmfPkg/Library/XenPciHostBridgeLib/XenPciHostBridge.h
> new file mode 100644
> index 000..c23d40c
> --- /dev/null
> +++ b/OvmfPkg/Library/XenPciHostBridgeLib/XenPciHostBridge.h
> @@ -0,0 +1,75 @@
> +/** @file
> +  Header file of OVMF instance of PciHostBridgeLib.
> +
> +  Copyright (c) 2016, Intel Corporation. All rights reserved.
> +
> +  This program and the accompanying materials are licensed and made available
> +  under the terms and conditions of the BSD License which accompanies this
> +  distribution.  The full text of the license may be found at
> +  http://opensource.org/licenses/bsd-license.php.
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
> WITHOUT
> +  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
> +PCI_ROOT_BRIDGE *
> +ScanForRootBridges (
> +  UINTN  *NumberOfRootBridges
> +);
> +
> +/**
> +  Initialize a PCI_ROOT_BRIDGE structure.
> +
> +  @param[in]  Supports Supported attributes.
> +
> +  @param[in]  Attributes   Initial attributes.
> +
> +  @param[in]  AllocAttributes  Allocation attributes.
> +
> +  @param[in]  RootBusNumberThe bus number to store in RootBus.
> +
> +  @param[in]  MaxSubBusNumber  The inclusive maximum bus number that can be
> +   assigned to any subordinate bus found behind 
> any
> +   PCI bridge hanging off this root bus.
> +
> +   The caller is repsonsible for ensuring that
> +   RootBusNumber <= MaxSubBusNumber. If
> +   RootBusNumber equals MaxSubBusNumber, then the
> +   root bus has no room for subordinate buses.
> +
> +  @param[in]  Io   IO aperture.
> +
> +  @param[in]  Mem  MMIO aperture.
> +
> +  @param[in]  MemAbove4G   MMIO aperture above 4G.
> +
> +  @param[in]  PMem Prefetchable MMIO aperture.
> +
> +  @param[in]  PMemAbove4G  Prefetchable MMIO aperture above 4G.
> +
> +  @param[out] RootBus  The PCI_ROOT_BRIDGE structure (allocated by 
> the
> +   caller) that should be filled in by this
> +   function.
> +
> +  @retval EFI_SUCCESS   Initialization successful. A device path
> +consisting of an ACPI device path node, with
> +UID = RootBusNumber, has been allocated and
> +linked into RootBus.
> +
> +  @retval EFI_OUT_OF_RESOURCES  Memory allocation failed.
> +**/
> +EFI_STATUS
> +InitRootBridge (
> +  IN  UINT64   Supports,
> +  IN  UINT64   Attributes,
> +  IN  UINT64   AllocAttributes,
> +  IN  UINT8RootBusNumber,
> +  IN  UINT8

Re: [Xen-devel] [edk2] [PATCH RFC 04/14] OvmfPkg: Introduce XenPlatformPei

[Laszlo Ersek]

On 12/08/16 16:33, Anthony PERARD wrote:
> A copy of OvmfPkg/PlatformPei without some of QEMU specific
> initialization, Xen does not support QemuFwCfg.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Anthony PERARD 
> ---
>  OvmfPkg/XenOvmf.dsc   |   2 +-
>  OvmfPkg/XenOvmf.fdf   |   2 +-
>  OvmfPkg/XenPlatformPei/Cmos.c |  64 
>  OvmfPkg/XenPlatformPei/Cmos.h |  56 
>  OvmfPkg/XenPlatformPei/Fv.c   | 100 ++
>  OvmfPkg/XenPlatformPei/MemDetect.c| 449 +
>  OvmfPkg/XenPlatformPei/Platform.c | 536 
> ++
>  OvmfPkg/XenPlatformPei/Platform.h | 104 ++
>  OvmfPkg/XenPlatformPei/Xen.c  | 231 +
>  OvmfPkg/XenPlatformPei/Xen.h  |  45 +++
>  OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 110 ++
>  11 files changed, 1697 insertions(+), 2 deletions(-)
>  create mode 100644 OvmfPkg/XenPlatformPei/Cmos.c
>  create mode 100644 OvmfPkg/XenPlatformPei/Cmos.h
>  create mode 100644 OvmfPkg/XenPlatformPei/Fv.c
>  create mode 100644 OvmfPkg/XenPlatformPei/MemDetect.c
>  create mode 100644 OvmfPkg/XenPlatformPei/Platform.c
>  create mode 100644 OvmfPkg/XenPlatformPei/Platform.h
>  create mode 100644 OvmfPkg/XenPlatformPei/Xen.c
>  create mode 100644 OvmfPkg/XenPlatformPei/Xen.h
>  create mode 100644 OvmfPkg/XenPlatformPei/XenPlatformPei.inf

(1) You might want to add Citrix copyright notices to new files.

(2) This module is a good example where the moved Xen functionality
(even for HVM guests) should be possible to remove from the original
PlatformPei module. (In a later, final patch.) Is that right?

(3) In the commit message, please list the removed fw_cfg-dependent
functionality in more detail (all of which is dynamically skipped when
the current PlatformPei module runs on Xen):

- GetFirstNonAddress(): controlling the 64-bit PCI MMIO aperture via the
(experimental) "opt/ovmf/X-PciMmio64Mb" file

- GetFirstNonAddress(): honoring the hotplug DIMM area
("etc/reserved-memory-end") in the placement of the 64-bit PCI MMIO aperture

- NoexecDxeInitialization() is removed, so PcdPropertiesTableEnable and
PcdSetNxForStack are left constant FALSE (not set dynamically from
"opt/ovmf/PcdXxxx")

- MaxCpuCountInitialization(), PublishPeiMemory(): the max CPU count is
not taken from the QemuFwCfgItemSmpCpuCount fw_cfg key;
PcdCpuMaxLogicalProcessorNumber is used intact and
PcdCpuApInitTimeOutInMicroSeconds is never changed or used.

- InitializeXenPlatform(), S3Verification(): S3 is assumed disabled (not
consulting "etc/system-states" via QemuFwCfgS3Enabled()).

- InstallFeatureControlCallback(): the feature control MSR is not set
from "etc/msr_feature_control"

Also removed:
-  SMRAM/TSEG-related low mem size adjusting (PcdSmmSmramRequire is
assumed FALSE) in PublishPeiMemory(),
- QemuInitializeRam() entirely,

(4) I think the removal of PcdSmmSmramRequire is incomplete. IMO this
PCD should either be removed completely (all uses, including the INF
reference), assuming a FALSE value in its place, or the PCD should not
be touched at all. The FeaturePcdGet() call in PublishPeiMemory() --
gating the "TSEG is chipped from the end of low RAM" stuff -- seems to
be singled out for removal for no good reason.

(5) It would be nice to hint at the reason (which is implemented in a
later patch) why a separate module is a good idea here. That is, why the
expected PVH2 functionality is best not added to the current PlatformPei
module.

Thanks
Laszlo

> 
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index 0a7ea21..ef32c33 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -496,7 +496,7 @@
>PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
>}
>  
> -  OvmfPkg/PlatformPei/PlatformPei.inf {
> +  OvmfPkg/XenPlatformPei/XenPlatformPei.inf {
>  
>PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
>}
> diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
> index f4609b0..c211f61 100644
> --- a/OvmfPkg/XenOvmf.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -157,7 +157,7 @@ INF  MdeModulePkg/Core/Pei/PeiMain.inf
>  INF  MdeModulePkg/Universal/PCD/Pei/Pcd.inf
>  INF  
> MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf
>  INF  MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
> -INF  OvmfPkg/PlatformPei/PlatformPei.inf
> +INF  OvmfPkg/XenPlatformPei/XenPlatformPei.inf
>  INF  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
>  INF  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
>  !if $(SMM_REQUIRE) == TRUE
> diff --git a/OvmfPkg/XenPlatformPei/Cmos.c b/OvmfPkg/XenPlatformPei/Cmos.c
> new file mode 100644
> index 000..48ed2cb
> --- /dev/null
> +++ b/OvmfPkg/XenPlatformPei/Cmos.c
> @@ -0,0 +1,64 @@
> +/** @file
> +  PC/AT CMOS access routines
> +
> +  Copyright (c) 2006 - 2009, Intel Corporation. All rights 

Re: [Xen-devel] [edk2] [PATCH RFC 00/14] Specific platform to run OVMF in Xen PVH and HVM guests

[Laszlo Ersek]

On 12/08/16 16:33, Anthony PERARD wrote:
> Hi,
> 
> I've started to create a Xen specifig plaform, in OvmfPkg/XenOvmf.dsc
> with the goal to make it work on both Xen HVM and Xen PVHv2

Does this mean we can ultimately move all Xen roles from the current
platform DSC files to the new Xen DSC file entirely?

If so (which I think I would like), then for each module M that exhibits
all of the following properties:
- M is dynamically customized to Xen vs. QEMU,
- M is replaced by a dedicated module M' in the Xen DSC,
I think we should also remove the Xen-specific code from the original M
(as last step, likely in separate patches).

In addition, Xen platform specific device drivers should be removed as
well from the original DSC files.

What do you think?

> The first few patches only create the platform and duplicate some code from
> OvmfPkg and the later patches (from OvmfPkg/XenPlatformPei: Add xen PVH
> specific code) makes OVMF boot in a Xen PVH guest, and can boot a Linux.
> 
> == Part 1: XenOvmf.dsc
> 
> - OvmfPkg: Create platform XenOvmf
> which for now remove virtio drivers and some SMM
> 
> - OvmfPkg/XenOvmf: Update debug IO port for Xen
> 
> - OvmfPkg/XenOvmf.dsc: Introduce XenResetVector
> Just for one change, enable cache in CR0 as on Xen, OVMF run from RAM, that
> disabling cache can make OVMF very slow.
> 

... I might reply to this email again (the remaining stuff), as I
progress with the review.

Thanks
Laszlo

> - OvmfPkg: Introduce XenPlatformPei
> remove some QEMU/KVM specific code from PlatformPei.
> 
> - OvmfPkg/Library: add XenPciHostBridgeLib
> same with PciHostBridgeLib
> 
> == Part 2: PVH enabled
> 
> - OvmfPkg/XenPlatformPei: Add xen PVH specific code
> To figure out the memory size from E820
> 
> - OvmfPkg/XenResetVector: Add new entry point for Xen PVH
> which is in 32bits
> 
> - OvmfPkg/PlatformBootManagerLib: Workaround missing PCI bus on Xen PVH
> to avoid the Unknown Host Bridge Device ID error
> 
> - OvmfPkg/ResetSystemLib: Add missing dependency on PciLib
> - UefiCpuPkg/BaseXApicX2ApicLib: Fix initialisation on my system and ...
> - OvmfPkg/XenOvmf: Adding XenTimerLocalApic
> to replace the ACPI timer
> 
> - OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn
> - OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables
> - XenOvmf: Use a different RTC
> which does always return the same value
> 
> == to build and boot
> 
> To build, simply run OvmfPkg/build.sh -p OvmfPkg/XenOvmf.dsc
> 
> To run, I currently use a loader, base on hvmloader which does some setup, 
> read
> the e820 and copy ovmf to the right place to start it.
> 
> The loader is avaible in branch `ovmf-pvhloader' from
> https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
> 
> And the guest I'm using:
> builder = 'hvm'
> memory = 512
> name = "pvh-ovmf"
> kernel = 'pvh-ovmf-loader'
> ramdisk='OVMF.fd'
> extra='ovmf=1'
> disk = [ 'file:iso/archlinux-2016.10.01-dual.iso,hdc:cdrom,r', ]
> device_model_version = 'none'
> serial = 'pty'
> 
> Anthony PERARD (14):
>   OvmfPkg: Create platform XenOvmf
>   OvmfPkg/XenOvmf: Update debug IO port for Xen
>   OvmfPkg/XenOvmf.dsc: Introduce XenResetVector
>   OvmfPkg: Introduce XenPlatformPei
>   OvmfPkg/Library: add XenPciHostBridgeLib
>   OvmfPkg/XenPlatformPei: Add xen PVH specific code
>   OvmfPkg/XenResetVector: Add new entry point for Xen PVH
>   OvmfPkg/PlatformBootManagerLib: Workaround missing PCI bus on Xen PVH
>   OvmfPkg/ResetSystemLib: Add missing dependency on PciLib
>   UefiCpuPkg/BaseXApicX2ApicLib: Fix initialisation on my system and ...
>   OvmfPkg/XenOvmf: Adding XenTimerLocalApic
>   OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn
>   OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables
>   XenOvmf: Use a different RTC
> 
>  .../Library/PlatformBootManagerLib/BdsPlatform.c   |  35 +
>  .../PlatformBootManagerLib.inf |   2 +
>  OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf  |   1 +
>  .../Library/XenPciHostBridgeLib/XenPciHostBridge.h |  75 ++
>  .../XenPciHostBridgeLib/XenPciHostBridgeLib.c  | 291 
>  .../XenPciHostBridgeLib/XenPciHostBridgeLib.inf|  58 ++
>  OvmfPkg/Library/XenPciHostBridgeLib/XenSupport.c   | 456 
>  OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c  | 263 +++
>  OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf|  45 ++
>  OvmfPkg/XenOvmf.dsc| 809 
> +
>  OvmfPkg/XenOvmf.fdf| 506 +
>  OvmfPkg/XenPlatformPei/Cmos.c  |  64 ++
>  OvmfPkg/XenPlatformPei/Cmos.h  |  56 ++
>  OvmfPkg/XenPlatformPei/Fv.c| 100 +++
>  OvmfPkg/XenPlatformPei/MemDetect.c | 520 +
>  OvmfPkg/XenPlatformPei/Platform.c  | 541 ++
>  OvmfPkg/XenPlatformPei/Platform.h  | 114 +++
>  OvmfPkg/XenPlatformPei/Xen.c   | 231 

Re: [Xen-devel] [edk2] [PATCH RFC 03/14] OvmfPkg/XenOvmf.dsc: Introduce XenResetVector

[Laszlo Ersek]

(1) I think the subject line should just say:

  OvmfPkg: Introduce XenResetVector

(2) New files are added in this patch; you might want to tag them with a
Citrix copyright notice.

(3) When formatting the next version of this series for posting, please
pass the "-C --find-copies-harder" options to git-format-patch. Those
will automatically format each patch in the series as a (copy, diff)
pair, whenever appropriate, and that way we can compare the changed
copies more easily against the originals.

On 12/08/16 16:33, Anthony PERARD wrote:
> Copy of OvmfPkg/ResetVector, with one changes:
>   - default_cr0: enable cache

(4) Please mention SEC_DEFAULT_CR0 and the bit that is flipped,
specifically.

> 
> Xen copy the OVMF code to RAM, there is no need for cache. Also, it
> makes OVMF slow to start on AMD.

(5) Wait, is the slow start already an issue (with QEMU/KVM) on AMD?
Because, in the past, we saw that happen: refer to commit 98f378a7be12.

Are you saying 98f378a7be12 was not entirely right for QEMU/KVM
(considering recent AMD processors, I guess?)?

Or that the SEC_DEFAULT_CR0 value is not right on AMD only with Xen?

> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Anthony PERARD 
> ---
>  OvmfPkg/XenOvmf.dsc|   2 +-
>  OvmfPkg/XenOvmf.fdf|   2 +-
>  OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm | 133 
> +
>  OvmfPkg/XenResetVector/Ia32/PageTables64.asm   |  93 +
>  OvmfPkg/XenResetVector/XenResetVector.inf  |  37 +++
>  OvmfPkg/XenResetVector/XenResetVector.nasmb|  66 
>  6 files changed, 331 insertions(+), 2 deletions(-)
>  create mode 100644 OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
>  create mode 100644 OvmfPkg/XenResetVector/Ia32/PageTables64.asm
>  create mode 100644 OvmfPkg/XenResetVector/XenResetVector.inf
>  create mode 100644 OvmfPkg/XenResetVector/XenResetVector.nasmb
> 
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index 5b3550d..0a7ea21 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -471,7 +471,7 @@
>  #
>  
> 
>  [Components]
> -  OvmfPkg/ResetVector/ResetVector.inf
> +  OvmfPkg/XenResetVector/XenResetVector.inf
>  
>#
># SEC Phase modules
> diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
> index d01454e..f4609b0 100644
> --- a/OvmfPkg/XenOvmf.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -123,7 +123,7 @@ READ_LOCK_STATUS   = TRUE
>  #
>  INF  OvmfPkg/Sec/SecMain.inf
>  
> -INF  RuleOverride=RESET_VECTOR OvmfPkg/ResetVector/ResetVector.inf
> +INF  RuleOverride=RESET_VECTOR OvmfPkg/XenResetVector/XenResetVector.inf
>  
>  
> 
>  [FV.PEIFV]
> diff --git a/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm 
> b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
> new file mode 100644
> index 000..d746427
> --- /dev/null
> +++ b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
> @@ -0,0 +1,133 @@
> +;--
> +; @file
> +; Transition from 16 bit real mode into 32 bit flat protected mode
> +;
> +; Copyright (c) 2008 - 2010, Intel Corporation. All rights reserved.
> +; This program and the accompanying materials
> +; are licensed and made available under the terms and conditions of the BSD 
> License
> +; which accompanies this distribution.  The full text of the license may be 
> found at
> +; http://opensource.org/licenses/bsd-license.php
> +;
> +; THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +; WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +;
> +;--
> +
> +%define SEC_DEFAULT_CR0  0x0023
> +%define SEC_DEFAULT_CR4  0x640
> +
> +BITS16
> +
> +;
> +; Modified:  EAX, EBX
> +;
> +TransitionFromReal16To32BitFlat:
> +
> +debugShowPostCode POSTCODE_16BIT_MODE
> +
> +cli
> +
> +mov bx, 0xf000
> +mov ds, bx
> +
> +mov bx, ADDR16_OF(gdtr)
> +
> +o32 lgdt[cs:bx]
> +
> +mov eax, SEC_DEFAULT_CR0
> +mov cr0, eax
> +
> +jmp LINEAR_CODE_SEL:dword ADDR_OF(jumpTo32BitAndLandHere)
> +BITS32
> +jumpTo32BitAndLandHere:
> +
> +mov eax, SEC_DEFAULT_CR4
> +mov cr4, eax
> +
> +debugShowPostCode POSTCODE_32BIT_MODE
> +
> +mov ax, LINEAR_SEL
> +mov ds, ax
> +mov es, ax
> +mov fs, ax
> +mov gs, ax
> +mov ss, ax
> +
> +OneTimeCallRet TransitionFromReal16To32BitFlat
> +
> +ALIGN   2
> +
> +gdtr:
> +dw  GDT_END - GDT_BASE - 1   ; GDT limit
> +dd  ADDR_OF(GDT_BASE)
> +
> +ALIGN   16
> +
> +;
> +; Macros for GDT entries
> +;
> +
> +%define  PRESENT_FLAG(p) (p << 7)
> +%define  DPL(dpl) 

Re: [Xen-devel] [edk2] [PATCH RFC 02/14] OvmfPkg/XenOvmf: Update debug IO port for Xen

[Laszlo Ersek]

On 12/08/16 16:33, Anthony PERARD wrote:
> This is a debug IO port that will output directly to the Xen Hypervisor
> console.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Anthony PERARD <anthony.per...@citrix.com>
> ---
>  OvmfPkg/XenOvmf.dsc | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index e452eb3..5b3550d 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -421,6 +421,9 @@
># Point to the MdeModulePkg/Application/UiApp/UiApp.inf
>gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
> 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
>  
> +  ## This flag is used to control the destination port for 
> PlatformDebugLibIoPort
> +  gUefiOvmfPkgTokenSpaceGuid.PcdDebugIoPort|0xe9
> +
>  
> 
>  #
>  # Pcd Dynamic Section - list of all EDK II PCD Entries defined by this 
> Platform
> 

This patch looks good to me:

Reviewed-by: Laszlo Ersek <ler...@redhat.com>

But I ask that in the next posting of the series, please format the
patches with the following settings in effect (specifically, "xfuncname"):

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-05

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-09

They ensure that the @@ hunk header above will explicitly name the the
[PcdsFixedAtBuild] section, which helps quite a bit with reviewing.

Thanks,
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] [PATCH RFC 01/14] OvmfPkg: Create platform XenOvmf

[Laszlo Ersek]

On 12/08/16 16:33, Anthony PERARD wrote:
> This is a copy of OvmfX64, removing VirtIO and some SMM.

(1) Please provide more details in the commit message:

- changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
- removed: VirtioLib class resolution
- removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
- removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
- changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
- removed: all UEFI_DRIVER modules for virtio devices

> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Anthony PERARD 
> ---
>  OvmfPkg/XenOvmf.dsc | 793 
> 
>  OvmfPkg/XenOvmf.fdf | 504 +
>  2 files changed, 1297 insertions(+)
>  create mode 100644 OvmfPkg/XenOvmf.dsc
>  create mode 100644 OvmfPkg/XenOvmf.fdf
> 
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> new file mode 100644
> index 000..e452eb3
> --- /dev/null
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -0,0 +1,793 @@
> +## @file
> +#  EFI/Framework Open Virtual Machine Firmware (OVMF) platform
> +#
> +#  Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
> +#  (C) Copyright 2016 Hewlett Packard Enterprise Development LP

(2) You might want to add a Citrix copyright notice here.

The rest looks good to me (I diffed these files against their originals).

Thanks
Laszlo

> +#
> +#  This program and the accompanying materials
> +#  are licensed and made available under the terms and conditions of the BSD 
> License
> +#  which accompanies this distribution. The full text of the license may be 
> found at
> +#  http://opensource.org/licenses/bsd-license.php
> +#
> +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +#
> +##
> +
> +
> +#
> +# Defines Section - statements that will be processed to create a Makefile.
> +#
> +
> +[Defines]
> +  PLATFORM_NAME  = Ovmf
> +  PLATFORM_GUID  = e3aa4fbe-9459-482d-bd40-d3f3b5f89d6e
> +  PLATFORM_VERSION   = 0.1
> +  DSC_SPECIFICATION  = 0x00010005
> +  OUTPUT_DIRECTORY   = Build/XenOvmf
> +  SUPPORTED_ARCHITECTURES= X64
> +  BUILD_TARGETS  = NOOPT|DEBUG|RELEASE
> +  SKUID_IDENTIFIER   = DEFAULT
> +  FLASH_DEFINITION   = OvmfPkg/XenOvmf.fdf
> +
> +  #
> +  # Defines for default states.  These can be changed on the command line.
> +  # -D FLAG=VALUE
> +  #
> +  DEFINE SECURE_BOOT_ENABLE  = FALSE
> +  DEFINE NETWORK_IP6_ENABLE  = FALSE
> +  DEFINE HTTP_BOOT_ENABLE= FALSE
> +  DEFINE SMM_REQUIRE = FALSE
> +
> +[BuildOptions]
> +  GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
> +  GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
> +  INTEL:RELEASE_*_*_CC_FLAGS   = /D MDEPKG_NDEBUG
> +  MSFT:RELEASE_*_*_CC_FLAGS= /D MDEPKG_NDEBUG
> +  GCC:*_*_*_CC_FLAGS   = -mno-mmx -mno-sse
> +!ifdef $(SOURCE_DEBUG_ENABLE)
> +  MSFT:*_*_X64_GENFW_FLAGS  = --keepexceptiontable
> +  GCC:*_*_X64_GENFW_FLAGS   = --keepexceptiontable
> +  INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable
> +!endif
> +
> +  #
> +  # Disable deprecated APIs.
> +  #
> +  MSFT:*_*_*_CC_FLAGS = /D DISABLE_NEW_DEPRECATED_INTERFACES
> +  INTEL:*_*_*_CC_FLAGS = /D DISABLE_NEW_DEPRECATED_INTERFACES
> +  GCC:*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
> +
> +[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> +  GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> +
> +# Force PE/COFF sections to be aligned at 4KB boundaries to support page 
> level
> +# protection of DXE_SMM_DRIVER/SMM_CORE modules
> +[BuildOptions.common.EDKII.DXE_SMM_DRIVER, 
> BuildOptions.common.EDKII.SMM_CORE]
> +  GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> +
> +
> +#
> +# SKU Identification section - list of all SKU IDs supported by this 
> Platform.
> +#
> +
> +[SkuIds]
> +  0|DEFAULT
> +
> +
> +#
> +# Library Class section - list of all Library Classes needed by this 
> Platform.
> +#
> +
> +[LibraryClasses]
> +  PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
> +  TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf
> +  PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
> +  BaseMemoryLib|MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf
> +  BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
> +  
> 

Re: [Xen-devel] [PATCH v3] OvmfPkg/build.sh: Make GCC5 the default toolchain, catch GCC43 and earlier

[Laszlo Ersek]

On 11/24/16 02:15, Konrad Rzeszutek Wilk wrote:
> v2:
>  * Changes suggested by Laszlo:
>- change the catch-all (*) to GCC5, from GCC44
>- remove the (5.*.*) pattern from GCC49
>- generate error for GCC < 4.4
> 
> In v3, also generate error for really GCC < 4.4, like GCC 1.
> 
> Reviewed-by: Laszlo Ersek <ler...@redhat.com>
> Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>
> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=62
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Konrad Rzeszutek Wilk <kon...@kernel.org>
> ---
> v1: Initial
> v2: Redo it per Laszlo suggestions
> v3: Fix up commit message per Jordan
> Also generate error for prehistoric versions of GCC, like 1.
> ---
>  OvmfPkg/build.sh | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
> index eb5eb73..95fe8fb 100755
> --- a/OvmfPkg/build.sh
> +++ b/OvmfPkg/build.sh
> @@ -83,6 +83,13 @@ case `uname` in
>Linux*)
>  gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
>  case $gcc_version in
> +  [1-3].*|4.[0-3].*)
> +echo OvmfPkg requires GCC4.4 or later
> +exit 1
> +;;
> +  4.4.*)
> +TARGET_TOOLS=GCC44
> +;;
>4.5.*)
>  TARGET_TOOLS=GCC45
>  ;;
> @@ -95,11 +102,11 @@ case `uname` in
>4.8.*)
>  TARGET_TOOLS=GCC48
>  ;;
> -  4.9.*|4.1[0-9].*|5.*.*)
> +  4.9.*)
>      TARGET_TOOLS=GCC49
>  ;;
>*)
> -TARGET_TOOLS=GCC44
> +TARGET_TOOLS=GCC5
>  ;;
>  esac
>  esac
> 

Tested-by: Laszlo Ersek <ler...@redhat.com>

(With gcc-4.8.)

Pushed as commit 2667ad40919a.

Thank you!
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] OvmfPkg/build.sh: Make GCC5 the default toolchain, catch GCC43 and earlier

[Laszlo Ersek]

On 11/23/16 16:01, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 23, 2016 at 03:55:11PM +0100, Laszlo Ersek wrote:
>> On 11/23/16 03:36, Konrad Rzeszutek Wilk wrote:
>>> From Laszlo:
>>> " change the catch-all (*) to GCC5, from GCC44
>>> - remove the (5.*.*) pattern from GCC49
>>> - add a branch (with multiple patterns if necessary) for gcc-4.3 and
>>>   earlier to exit with an error message / failure (those compiler
>>>   versions are unsupported)"
>>>
>>> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=62
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Konrad Rzeszutek Wilk <kon...@kernel.org>
>>> ---
>>> v1: First submission
>>> v2: Redo it per Laszlo suggestion.
>>>
>>>  OvmfPkg/build.sh | 11 +--
>>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
>>> index eb5eb73..cab7c70 100755
>>> --- a/OvmfPkg/build.sh
>>> +++ b/OvmfPkg/build.sh
>>> @@ -83,6 +83,13 @@ case `uname` in
>>>Linux*)
>>>  gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
>>>  case $gcc_version in
>>> +  4.1.[0-0].*|4.2.*|4.3.*)
>>
>> * The [0-0] bracketed expression will work as expected, but it's
>> somewhat unusual :) Is it intentional?
>>
>> * If it's a typo, are you okay if I replace it with a plain 0 on commit?
> 
> It is a typo! It was 0-9 but I forgot to type 'git commit --amend'. Argh!
> 
> Are you OK doing:
> 
>  s/[0-0]/[0-9]/
> 
> when you commit or would you prefer I repost this with this in _and_ with
> your Reviewed-by?

I highly appreciate that you are willing to repost :) So yes, I'd like
to request you do that.

However, since you are willing to repost :), I also ask that you to
reformat the commit message as suggested by Jordan:

  https://lists.01.org/pipermail/edk2-devel/2016-November/005087.html

and to update the line that you are about to modify anyway, to:

  [1-3].*|4.[0-3].*)

  https://lists.01.org/pipermail/edk2-devel/2016-November/005129.html

If you agree, of course. (I'm not trying to be an annoyance on purpose.)

Thank you for working on this!
Laszlo

> 
>>
>> * Also, IIRC, Olaf considered pre-4.0 gcc releases as well (rejecting
>> them of course), which is sort of meant as part of "gcc-4.3 and
>> earlier". But, given your extensive testing with old distros (thanks for
> 
> Oh gosh.
>> that!), I think it's safe to ignore pre-4.0 gcc releases altogether.
> 
> Yes :-)
>>
>> Reviewed-by: Laszlo Ersek <ler...@redhat.com>
>>
>> Thanks!
>> Laszlo
>>
>>> +echo OvmfPkg requires GCC4.4 or later
>>> +exit 1
>>> +;;
>>> +  4.4.*)
>>> +TARGET_TOOLS=GCC44
>>> +;;
>>>4.5.*)
>>>  TARGET_TOOLS=GCC45
>>>  ;;
>>> @@ -95,11 +102,11 @@ case `uname` in
>>>4.8.*)
>>>  TARGET_TOOLS=GCC48
>>>  ;;
>>> -  4.9.*|4.1[0-9].*|5.*.*)
>>> +  4.9.*)
>>>  TARGET_TOOLS=GCC49
>>>  ;;
>>>*)
>>> -TARGET_TOOLS=GCC44
>>> +TARGET_TOOLS=GCC5
>>>  ;;
>>>  esac
>>>  esac
>>>
>>
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> https://lists.xen.org/xen-devel


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] OvmfPkg/build.sh: Make GCC5 the default toolchain, catch GCC43 and earlier

[Laszlo Ersek]

On 11/23/16 15:55, Laszlo Ersek wrote:
> On 11/23/16 03:36, Konrad Rzeszutek Wilk wrote:
>> From Laszlo:
>> " change the catch-all (*) to GCC5, from GCC44
>> - remove the (5.*.*) pattern from GCC49
>> - add a branch (with multiple patterns if necessary) for gcc-4.3 and
>>   earlier to exit with an error message / failure (those compiler
>>   versions are unsupported)"
>>
>> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=62
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Konrad Rzeszutek Wilk <kon...@kernel.org>
>> ---
>> v1: First submission
>> v2: Redo it per Laszlo suggestion.
>>
>>  OvmfPkg/build.sh | 11 +--
>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
>> index eb5eb73..cab7c70 100755
>> --- a/OvmfPkg/build.sh
>> +++ b/OvmfPkg/build.sh
>> @@ -83,6 +83,13 @@ case `uname` in
>>Linux*)
>>  gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
>>  case $gcc_version in
>> +  4.1.[0-0].*|4.2.*|4.3.*)
> 
> * The [0-0] bracketed expression will work as expected, but it's
> somewhat unusual :) Is it intentional?
> 
> * If it's a typo, are you okay if I replace it with a plain 0 on commit?

On a second thought, perhaps you meant

  4.0.*|4.1.*|4.2.*|4.3.*)

or

  4.[0-3].*)

If you wish to re-submit for this, we could consider those pre-4
releases as well:

  [1-3].*|4.[0-3].*)

Thanks!
Laszlo

> * Also, IIRC, Olaf considered pre-4.0 gcc releases as well (rejecting
> them of course), which is sort of meant as part of "gcc-4.3 and
> earlier". But, given your extensive testing with old distros (thanks for
> that!), I think it's safe to ignore pre-4.0 gcc releases altogether.
> 
> Reviewed-by: Laszlo Ersek <ler...@redhat.com>
> 
> Thanks!
> Laszlo
> 
>> +echo OvmfPkg requires GCC4.4 or later
>> +exit 1
>> +;;
>> +  4.4.*)
>> +TARGET_TOOLS=GCC44
>> +;;
>>4.5.*)
>>  TARGET_TOOLS=GCC45
>>  ;;
>> @@ -95,11 +102,11 @@ case `uname` in
>>4.8.*)
>>  TARGET_TOOLS=GCC48
>>  ;;
>> -  4.9.*|4.1[0-9].*|5.*.*)
>> +  4.9.*)
>>  TARGET_TOOLS=GCC49
>>  ;;
>>*)
>> -TARGET_TOOLS=GCC44
>> +TARGET_TOOLS=GCC5
>>  ;;
>>  esac
>>  esac
>>
> 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] OvmfPkg/build.sh: Make GCC5 the default toolchain, catch GCC43 and earlier

[Laszlo Ersek]

On 11/23/16 03:36, Konrad Rzeszutek Wilk wrote:
> From Laszlo:
> " change the catch-all (*) to GCC5, from GCC44
> - remove the (5.*.*) pattern from GCC49
> - add a branch (with multiple patterns if necessary) for gcc-4.3 and
>   earlier to exit with an error message / failure (those compiler
>   versions are unsupported)"
> 
> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=62
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Konrad Rzeszutek Wilk <kon...@kernel.org>
> ---
> v1: First submission
> v2: Redo it per Laszlo suggestion.
> 
>  OvmfPkg/build.sh | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
> index eb5eb73..cab7c70 100755
> --- a/OvmfPkg/build.sh
> +++ b/OvmfPkg/build.sh
> @@ -83,6 +83,13 @@ case `uname` in
>Linux*)
>  gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
>  case $gcc_version in
> +  4.1.[0-0].*|4.2.*|4.3.*)

* The [0-0] bracketed expression will work as expected, but it's
somewhat unusual :) Is it intentional?

* If it's a typo, are you okay if I replace it with a plain 0 on commit?

* Also, IIRC, Olaf considered pre-4.0 gcc releases as well (rejecting
them of course), which is sort of meant as part of "gcc-4.3 and
earlier". But, given your extensive testing with old distros (thanks for
that!), I think it's safe to ignore pre-4.0 gcc releases altogether.

Reviewed-by: Laszlo Ersek <ler...@redhat.com>

Thanks!
Laszlo

> +echo OvmfPkg requires GCC4.4 or later
> +exit 1
> +;;
> +  4.4.*)
> +TARGET_TOOLS=GCC44
> +;;
>4.5.*)
>  TARGET_TOOLS=GCC45
>  ;;
> @@ -95,11 +102,11 @@ case `uname` in
>4.8.*)
>  TARGET_TOOLS=GCC48
>  ;;
> -  4.9.*|4.1[0-9].*|5.*.*)
> +  4.9.*)
>  TARGET_TOOLS=GCC49
>  ;;
>*)
> -TARGET_TOOLS=GCC44
> +TARGET_TOOLS=GCC5
>  ;;
>  esac
>  esac
> 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] [PATCH RESEND] OvmfPkg/build.sh: Use GCC49 toolchain with GCC 6.*

[Laszlo Ersek]

On 11/21/16 17:20, Ard Biesheuvel wrote:
> On 21 November 2016 at 15:56, Konrad Rzeszutek Wilk  wrote:
>> Without this I cannot build it under Fedora Core 25.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Konrad Rzeszutek Wilk 
>> ---
>>  OvmfPkg/build.sh | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
>> index eb5eb73..759ade3 100755
>> --- a/OvmfPkg/build.sh
>> +++ b/OvmfPkg/build.sh
>> @@ -95,7 +95,7 @@ case `uname` in
>>4.8.*)
>>  TARGET_TOOLS=GCC48
>>  ;;
>> -  4.9.*|4.1[0-9].*|5.*.*)
>> +  4.9.*|4.1[0-9].*|5.*.*|6.*.*)
>>  TARGET_TOOLS=GCC49
>>  ;;
>>*)
> 
> I think it may be time to start using GCC5 for 5.x and later

I agree.

We have an open BZ for this:

https://bugzilla.tianocore.org/show_bug.cgi?id=62

Olaf Hering submitted a patch around June, but the formalities on those
patches weren't right, and Olaf decided not to submit further versions
of the patch.

Here's the idea:
- change the catch-all (*) to GCC5, from GCC44
- remove the (5.*.*) pattern from GCC49
- add a branch (with multiple patterns if necessary) for gcc-4.3 and
  earlier to exit with an error message / failure (those compiler
  versions are unsupported)

Konrad, can you please submit a v2 with this? If so, please add the tag

Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=62

as well, just before the "Contributed-under:" tag.

(Side note: we haven't been ignoring BZ#62. It's just that after
reviewing Olaf's original patch, implementing the change -- which is
very simple and cannot really be done in different ways -- in his stead
would have practically consisted of replacing Olaf's signoff with
someone elses, and we couldn't do that.)

Thank you,
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] edk2 compile error

[Laszlo Ersek]

On 09/18/16 05:38, Chen, Farrah wrote:
> Hi,
> 
> When I compile xen with the latest commit in RHEL 6.7, it failed when make 
> tools. Errors showed when running edk2 build for OvmfPkgX64.
> Bisected and this error occurred from commit 
> 8c8b6fb02342f7aa78e611a5f0f63dcf8fbf48f2.
> 
> commit 8c8b6fb02342f7aa78e611a5f0f63dcf8fbf48f2
> Author: Wei Liu >
> Date:   Tue Sep 6 12:54:47 2016 +0100
> 
> Config.mk: update OVMF commit
> 
> Signed-off-by: Wei Liu wei.l...@citrix.com
> 
> 
> We have updated OVMF to the latest master and cleaned everything before 
> rebuilding.
> 
> 
> 
> Steps:
> 
> make clean
> 
> make xen -j8
> 
> ./configure --enable-ovmf
> 
> make tools -j8
> 
> Then the error occurred.
> 
> 
> 
> 
> 
> I also tried:
> 
> git clone https://github.com/tianocore/edk2.git
> 
> cd edk2
> 
> OvmfPkg/build.sh -a X64 -b DEBUG -n 4
> The same error occurred.
> .
> 
> log:
> ..
> Running edk2 build for OvmfPkgX64
> ..
> /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:173:
>  error: invalid combination of opcode and operands
> /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:175:
>  error: invalid combination of opcode and operands
> /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:177:
>  error: invalid combination of opcode and operands
> /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:179:
>  error: invalid combination of opcode and operands
> /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:313:
>  error: invalid combination of opcode and operands
> /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:315:
>  error: invalid combination of opcode and operands
> make[7]: Leaving directory 
> `/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib'
> make[7]: *** 
> [/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.obj]
>  Error 1
> 
> 
> build.py...
> : error 7000: Failed to execute command
> make tbuild 
> [/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib]
> 
> 
> build.py...
> : error F002: Failed to build module
> 
> /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
>  [X64, GCC44, DEBUG]
> 
> - Failed -

RHEL-6 does not have a nasm version that is recent enough to build edk2.
RHEL-6 ships nasm-2.07-*, but edk2 requires nasm-2.10 or later with the
GCC toolchain family.

Please see this mailing list thread:
https://www.mail-archive.com/edk2-devel@lists.01.org/msg14420.html

And the resultant docs commit:
https://github.com/tianocore/edk2/commit/9c4dbdff1d56

... Before anyone suggests otherwise, this was not a gratuitous version
requirement bump. The edk2 assembly code had already been there, the
nasm version bump only documented the status, after the fact.

For RHEL-6 specifically, I suggest to grab a recent enough nasm SRPM
from Fedora Koji, and rebuild / install that locally. Better yet, I
recommend upgrading to RHEL-7, whose nasm is good enough.

Thanks
Laszlo


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] OVMF for Xen PVH

[Laszlo Ersek]

On 09/08/16 11:38, Anthony PERARD wrote:
> Hello,
> 
> We are introducing a new virtualisation mode in Xen called PVHv2 (also
> called hvmlite in the past). We would like to have a UEFI firmware
> running on it to make it easier to start a guest. (Right now, I think it
> involves supplying the guest kernel to the guest config, like a PV
> guest.)
> 
> I'm exploring different possibility of what could be done, and what
> should be avoided. It would be nice to have only one binary for both
> PVHv2 guest and HVM guest.
> 
> Would it be possible to introduce a different entry point in OVMF? The
> current one cannot be used at the start of the day of a PVHv2 guest.
> 
> If not, we'll try to use the current entry point or create a new package
> like it has been done for Xen on ARM.
> 
> Thanks for any feedback,
> 

I've been thinking about having a shared OVMF binary for Xen and
QEMU/KVM (from a different perspective), and I did recall that ArmVirt
has separate platform DSCs / FDFs for Xen and QEMU.

The question that made me think about this is the number and size of
modules that we now build into the OVMF binary. The binary has been
continuously growing (internally), and while Ard did some fantastic work
on enabling -Os for a bunch of edk2 compilers and platforms, the
compressed size (= the ultimate utilization of the flash chip) has not
gone down significantly, if I recall correctly.

Growing the non-compressed DXEFV (which -Os mitigates significantly) is
not terribly hard, as long as we don't outgrow OVMF_CODE.fd (1920 KB),
i.e., the external thingy after compression. Outgrowing OVMF_CODE.fd
might be major pain for distros however, so I've been thinking about
trimming the builds statically.

There's some low hanging fruit for that; for example the virtio drivers
should only go into the qemu/KVM build, same for the SMM driver stack,
same for the pflash driver. Whereas the XenPV drivers, the FS-based
varstore emulation, etc should go only into the Xen build.

So, from this (independent) POV, I'd prefer separate builds for Xen and
qemu/KVM.

Regarding the entry point itself, the SMM work has complicated those
early (= SEC / PEI) modules quite a bit (for example, grep OvmfPkg for
"PcdSmmSmramRequire"). I think if you start with a separate platform,
that will make your work easier (giving you more freedom in
accommodating both PVHv2 and HVM, without regard to qemu/KVM), and allow
me to keep my sanity -- think regressions, reviews, etc :)

Here's another point I've been thinking about, on-and-off: I find it
regrettable that we don't have any official co-maintainer in
Maintainers.txt for OvmfPkg's Xen parts. We've regressed Xen a few times
in the past because none of the OvmfPkg co-maintainers run Xen. This
should certainly be fixed.

Now, if you create a new platform (DSC + FDF) for Xen, that sort of
forces someone from the Xen community to assume co-maintainership for
the Xen bits. (Hopefully those bits would be easily identifiable by
pathname.) I'd welcome that *very much*.

So, I prefer a separate platform. I'd suggest to extract the Xen
platform with the current functionality first (with all those additional
benefits), then rework the new Xen platform to accommodate PVHv2 as well
(possibly with different Sec / PlatformPei modules etc).

Do wait for feedback from Jordan please.

Thanks
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] OvmfPkg: Add ACPI support for Virt Xen ARM

[Laszlo Ersek]

On 05/31/16 06:59, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> Add ACPI support for Virt Xen ARM and it gets the ACPI tables through
> Xen ARM multiboot protocol.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Shannon Zhao 
> ---
> The corresponding Xen patches can be fetched from:
> http://git.linaro.org/people/shannon.zhao/xen.git/shortlog/refs/heads/domu_acpi
> ---
>  ArmVirtPkg/ArmVirtXen.dsc |   6 +
>  ArmVirtPkg/ArmVirtXen.fdf |   6 +
>  OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h|   6 +
>  OvmfPkg/AcpiPlatformDxe/XenArmAcpi.c  | 207 
> ++
>  OvmfPkg/AcpiPlatformDxe/XenArmAcpiPlatform.c  |  38 
>  OvmfPkg/AcpiPlatformDxe/XenArmAcpiPlatformDxe.inf |  59 ++
>  6 files changed, 322 insertions(+)
>  create mode 100644 OvmfPkg/AcpiPlatformDxe/XenArmAcpi.c
>  create mode 100644 OvmfPkg/AcpiPlatformDxe/XenArmAcpiPlatform.c
>  create mode 100644 OvmfPkg/AcpiPlatformDxe/XenArmAcpiPlatformDxe.inf

Jordan and I might disagree about this patch, but here's my comments
about it:

I don't think this patch belongs under OvmfPkg. Namely, the only file
that XenArmAcpiPlatformDxe reuses from the existing
OvmfPkg/AcpiPlatformDxe/ directory is "EntryPoint.c", which is (a)
trivial, (b) its conditions and branches should be possible to evaluate
statically for aarch64 Xen. (PcdPciDisableBusEnumeration should be set
to TRUE in ArmVirtXen.dsc.)

Second, the new code uses the FDT library directly (from EmbeddedPkg),
and accesses QEMU's DTB directly (with the fdt_*() APIs). However, in
ArmVirtPkg we have moved away from this, and now we have a custom
(edk2-only, non-standard) FdtClient protocol for accessing the FDT.
Please see:
- ArmVirtPkg/Include/Protocol/FdtClient.h
- ArmVirtPkg/FdtClientDxe/

In order to rebase this patch to the FDT Client Protocol, while keeping
it under OvmfPkg, the "XenArmAcpiPlatformDxe.inf" file would have to
list "ArmVirtPkg/ArmVirtPkg.dec" in the [Packages] section. I think that
would be very ugly. Thus far we have managed to avoid mutual references
between OvmfPkg and ArmVirtPkg: OvmfPkg doesn't consume anything from
ArmVirtPkg, and that's how things should stay in my opinion.

Which is why I suggest to implement this functionality entirely under
ArmVirtPkg, and using the FDT Client Protocol at that.

If a non-trivial chunk of functionality can be identified between
OvmfPkg and ArmVirtPkg in this regard (that currently exists under
OvmfPkg/AcpiPlatformDxe/), then it should be extracted into a library
(under OvmfPkg/Include/Library and OvmfPkg/Library), and the ArmVirtPkg
code should become a client of that library. (You can find many similar
OvmfPkg/Library/ resolutions in the ArmVirtPkg/ DSC files.)

NB: Ard is going to be on vacation for a while, and I think we should
definitely await his feedback on this. First, my participation in
ArmVirtXen matters is quite minimal. Second, Ard designed the FDT Client
Protocol; in case you need extensions to the current APIs for
implementing the feature, then Ard is the one to review them.

Thanks,
Laszlo

> diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
> index 594ca64..a0d197f 100644
> --- a/ArmVirtPkg/ArmVirtXen.dsc
> +++ b/ArmVirtPkg/ArmVirtXen.dsc
> @@ -216,3 +216,9 @@
>  
>OvmfPkg/XenBusDxe/XenBusDxe.inf
>OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> +
> +  #
> +  # ACPI Support
> +  #
> +  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
> +  OvmfPkg/AcpiPlatformDxe/XenArmAcpiPlatformDxe.inf
> diff --git a/ArmVirtPkg/ArmVirtXen.fdf b/ArmVirtPkg/ArmVirtXen.fdf
> index 13412f9..da30e87 100644
> --- a/ArmVirtPkg/ArmVirtXen.fdf
> +++ b/ArmVirtPkg/ArmVirtXen.fdf
> @@ -179,6 +179,12 @@ READ_LOCK_STATUS   = TRUE
>INF OvmfPkg/XenBusDxe/XenBusDxe.inf
>INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
>  
> +  #
> +  # ACPI Support
> +  #
> +  INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
> +  INF OvmfPkg/AcpiPlatformDxe/XenArmAcpiPlatformDxe.inf
> +
>  [FV.FVMAIN_COMPACT]
>  FvAlignment= 16
>  ERASE_POLARITY = 1
> diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h 
> b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
> index 08dd7f8..325d7e6 100644
> --- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
> +++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
> @@ -69,6 +69,12 @@ InstallXenTables (
>  
>  EFI_STATUS
>  EFIAPI
> +InstallXenArmTables (
> +  IN   EFI_ACPI_TABLE_PROTOCOL   *AcpiProtocol
> +  );
> +
> +EFI_STATUS
> +EFIAPI
>  InstallQemuFwCfgTables (
>IN   EFI_ACPI_TABLE_PROTOCOL   *AcpiProtocol
>);
> diff --git a/OvmfPkg/AcpiPlatformDxe/XenArmAcpi.c 
> b/OvmfPkg/AcpiPlatformDxe/XenArmAcpi.c
> new file mode 100644
> index 000..c3a351c
> --- /dev/null
> +++ b/OvmfPkg/AcpiPlatformDxe/XenArmAcpi.c
> @@ -0,0 +1,207 @@
> +/** @file
> +  OVMF ACPI Xen ARM support
> +
> +  Copyright (C) 2016, Linaro Ltd. All rights reserved.
> +
> 

Re: [Xen-devel] [edk2] OVMF broken under Xen (in PCI initialisation)

[Laszlo Ersek]

On 04/28/16 07:08, Ni, Ruiyu wrote:


 Do you know whether Xen passes the PCI device resource
 information to firmware?
>>
>> I don't think so, no.
>>
>> But, given that the previous PciHostBridgeDxe driver was working on Xen,
>> can we perhaps emulate that behavior in
>> "OvmfPkg/Library/PciHostBridgeLib" somehow?
> 
> Let me explain the reason why previous PciHostBridgeDxe driver was
> working on Xen:
> The PciRootBridgeIo.Configuration() in new driver only create resource
> descriptor when the resource status is allocated:
> 
> if (ResAllocNode->Status != ResAllocated) {
>   continue;
> }
> 
> The same function in old driver doesn't check the Status field so it
> unconditionally returns BUS descriptor with AddrRangeMin and
> AddrRangeMax both equal 0. So that PciEnumeratorLight()
> in PciBus driver can still search the devices from starting bus 0.
> It just happened to work.
> 
> I think the new driver's Configuration() implementation is correct
> while the old driver's one is wrong. So I don't want to change to 
> wrong implementation to fix this issue.

Makes sense, thank you for the explanation.

> The issue can be resolved if we have a way to tell PciBus
> PciEnumeratorLight() which bus number to start searching.
> 
> It's almost true that starting bus number for root bridge #0
> is 0. But it might not be true for the rest root bridges.
> 
> OVMF's PciHostBridgeLib currently returns multiple root bridges
> and for root bridge #1, the starting bus number is obviously
> not 0 unless "etc/extra-pci-roots" doesn't exist or is 0 so there is
> only one root bridge.
> 
> My question is in OVMF over Xen, does "etc/extra-pci-roots" exist?
> If it exists, device behind root bridge #1, #2... can *not* be found
> with the current implementation.

"etc/extra-pci-roots" (more precisely, fw_cfg in general) is specific to
QEMU. QemuFwCfgLib runs alright in Xen guests, but whenever you look for
an fw_cfg file, it is not found -- which is good behavior.

So, OVMF's PciHostBridgeLib produces exactly one PCI_ROOT_BRIDGE object
when it runs on Xen. ExtraRootBridges is set to zero, the loop runs zero
times, and the one InitRootBridge() call after the loop produces one
PCI_ROOT_BRIDGE object, with the following parameters:
- Bus.Base = 0
- Bus.Limit = PCI_MAX_BUS

Thanks
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] OVMF broken under Xen (in PCI initialisation)

[Laszlo Ersek]

On 04/27/16 11:50, Ni, Ruiyu wrote:
> Copying Mike.
> 
> Regards,
> Ray
> 
>> -Original Message-
>> From: Ni, Ruiyu
>> Sent: Wednesday, April 27, 2016 5:49 PM
>> To: 'Gary Lin' <g...@suse.com>
>> Cc: edk2-de...@lists.01.org; Xen Devel <xen-devel@lists.xen.org>; Laszlo 
>> Ersek <ler...@redhat.com>
>> Subject: RE: [edk2] OVMF broken under Xen (in PCI initialisation)
>>
>> Gary,
>> Thanks for the try.
>>
>> I now understand why the issue happens.
>> 1. PciEnumeratorLight() depends on the MinBus returned from
>> PciRootBridgeIo.Configuration().
>> 2. PciRootBridgeIo.Configuration() returns the resource descriptors
>> initialized by PciHostBridge.NotifyPhase(EfiPciHostBridgeAllocateResources).
>> 3. PciHostBridge.NotifyPhase(EfiPciHostBridgeAllocateResources)
>> is not called when PcdPciDisableBusEnumeration is TRUE
>>
>> I am thinking about let PciRootBridgeIo.Configuration() returns
>> the correct resource consumption information even when
>> PcdPciDisableBusEnumeration is TRUE.
>>
>> I can add a new field to PCI_ROOT_BRIDGE structure defined in
>> MdeModulePkg/Include/Library/PciHostBridgeLib.h to indicate
>> that the resources filled in PCI_ROOT_BRIDGE.Bus/Io/Mem/
>> MemAbove4G/PMem/PMemAbove4G are already assigned
>> to PCI bus. So that PciRootBridgeIo.Configuration() can return
>> these value even when
>> PciHostBridge.NotifyPhase(EfiPciHostBridgeAllocateResources)
>> is not called due to PcdPciDisableBusEnumeration is TRUE.

Can you use PcdPciDisableBusEnumeration directly for this?

(If you don't like the idea, we could certainly set the new field in
PCI_ROOT_BRIDGE from the PCD too, in OvmfPkg/Library/PciHostBridgeLib.)

>> Do you know whether Xen passes the PCI device resource
>> information to firmware?

I don't think so, no.

But, given that the previous PciHostBridgeDxe driver was working on Xen,
can we perhaps emulate that behavior in
"OvmfPkg/Library/PciHostBridgeLib" somehow?

Do you think that step (2) above behaves differently between the old and
the new PCI host bridge driver? (Steps (1) and (3) should be identical,
they are initiated by the PCI Bus driver.)

Thanks
Laszlo

>>
>> Copying Laszlo.
>>
>> Regards,
>> Ray
>>
>>> -Original Message-
>>> From: Gary Lin [mailto:g...@suse.com]
>>> Sent: Wednesday, April 27, 2016 4:27 PM
>>> To: Ni, Ruiyu <ruiyu...@intel.com>
>>> Cc: edk2-de...@lists.01.org; Xen Devel <xen-devel@lists.xen.org>
>>> Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
>>>
>>> On Wed, Apr 27, 2016 at 07:18:21AM +, Ni, Ruiyu wrote:
>>>> Gary,
>>>> In PciEnumeratorLight(), please directly assign 0 to MinBus when
>>>> Configuration() returns error, instead of calling PciGetBusRange() to
>>>> extract MinBus from the descriptors returned from Configuration().
>>>>
>>> OK, I ignored PciGetBusRange() and the check of the return status of
>>> Configuration(). Since MinBus is already initialized, I don't bother to
>>> change the value anyway. The change is attached.
>>>
>>> And yes, this time the shell showed.
>>>
>>> Thanks,
>>>
>>> Gary Lin
>>>
>>>> Regards,
>>>> Ray
>>>>
>>>>> -Original Message-
>>>>> From: Gary Lin [mailto:g...@suse.com]
>>>>> Sent: Wednesday, April 27, 2016 2:54 PM
>>>>> To: Ni, Ruiyu <ruiyu...@intel.com>
>>>>> Cc: edk2-de...@lists.01.org; Xen Devel <xen-devel@lists.xen.org>
>>>>> Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
>>>>>
>>>>> On Wed, Apr 27, 2016 at 05:39:40AM +, Ni, Ruiyu wrote:
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Ray
>>>>>>
>>>>>>> -Original Message-
>>>>>>> From: Gary Lin [mailto:g...@suse.com]
>>>>>>> Sent: Wednesday, April 27, 2016 12:29 PM
>>>>>>> To: Ni, Ruiyu <ruiyu...@intel.com>
>>>>>>> Cc: edk2-de...@lists.01.org; Xen Devel <xen-devel@lists.xen.org>
>>>>>>> Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
>>>>>>>
>>>>>>> On Tue, Apr 26, 2016 at 09:40:42AM +, Ni, Ruiyu wrote:
>>>>>>>> Gary,
>>>>>>>> I can reproduce the issue and have debugg

Re: [Xen-devel] [edk2] OVMF broken under Xen (in PCI initialisation)

[Laszlo Ersek]

On 04/22/16 16:47, Anthony PERARD wrote:
> Hi,
> 
> Following the switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe, the pci root
> bridge does not finish to initialize and breaks under Xen.

(Adding Ray Ni)

> There are several issue probably due to the use of
> PcdPciDisableBusEnumeration=TRUE.
> 
> First one:
> ASSERT MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c(99): 
> Bridge->Mem.Limit < 0x0001ULL
> 
> This patch would fix the first assert:
> diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/Xen.c
> index 7fa9019..15ec7a7 100644
> --- a/OvmfPkg/PlatformPei/Xen.c
> +++ b/OvmfPkg/PlatformPei/Xen.c
> @@ -227,5 +227,11 @@ InitializeXen (
> 
>PcdSetBool (PcdPciDisableBusEnumeration, TRUE);
> 
> +  // Values from hvmloader
> +#define PCI_MEM_END 0xFC00
> +#define HVM_BELOW_4G_MMIO_START 0xF000
> +  PcdSet64 (PcdPciMmio32Base, HVM_BELOW_4G_MMIO_START);
> +  PcdSet64 (PcdPciMmio32Size, PCI_MEM_END - HVM_BELOW_4G_MMIO_START);
> +
>return EFI_SUCCESS;
>  }

For this, I am to blame; sorry about the regression. Can you please
submit the change as a standalone patch, and mention commit
03845e90cc432 as the one that missed it?

Also, can you please add the macros to "OvmfPkg/PlatformPei/Xen.h"
instead, near OVMF_INFO_PHYSICAL_ADDRESS?

> 
> 
> But that not enough, next assert is:
> ASSERT MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c(807): RootBridge != 
> ((void *) 0)
> 
> I have worked around this one with the following patch. That would
> correspond to how the former implementation in OvmfPkg was initializing the
> struct. Maybe a better way would be to fill ResAllocated under Xen,
> somehow. Under Xen, the ResAllocNode status is not allocated, so no
> Descriptor are created.
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c 
> b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> index cda9b49..eda92b6 100644
> --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> @@ -1509,15 +1509,13 @@ RootBridgeIoConfiguration (
> 
>  ResAllocNode = >ResAllocNode[Index];
> 
> -if (ResAllocNode->Status != ResAllocated) {
> -  continue;
> -}
> -
>  Descriptor->Desc = ACPI_ADDRESS_SPACE_DESCRIPTOR;
>  Descriptor->Len  = sizeof (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) - 3;
> +if (ResAllocNode->Status != ResAllocated) {
>  Descriptor->AddrRangeMin  = ResAllocNode->Base;
>  Descriptor->AddrRangeMax  = ResAllocNode->Base + ResAllocNode->Length - 
> 1;
>  Descriptor->AddrLen   = ResAllocNode->Length;
> +}
>  switch (ResAllocNode->Type) {
> 
> 
> That leads to one last assert:
>> QemuVideo: Cirrus 5446 detected
>> InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B 7B9EF598
>> Adding Mode 0 as Cirrus Internal Mode 0: 640x480, 32-bit, 60 Hz
>> Adding Mode 1 as Cirrus Internal Mode 1: 800x600, 32-bit, 60 Hz
>> Adding Mode 2 as Cirrus Internal Mode 2: 1024x768, 24-bit, 60 Hz
>> PixelBlueGreenRedReserved8BitPerColor
>> ASSERT 
>> /local/home/sheep/work/ovmf/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c(1789): 
>> ((BOOLEAN)(0==1))
> For this one, I've workaround by reverting patch 7b0a1ea
> (MdeModuelPkg/PciBus: Return AddrTranslationOffset in GetBarAttributes).
> That issue was introduce while still using the USE_OLD_PCI_HOST.
> 
> Any idee or pointer on how to fix those issues ?

I think your suggestion that PcdPciDisableBusEnumeration=TRUE causes
these problems is likely correct. Both of the above issues seem to
originate from PciHostBridgeDxe's assumption that resources have been
allocated (i.e., there has been an enumeration).

Please discuss these questions with Ray -- I guess PciHostBridgeDxe may
not have received a lot of testing with
PcdPciDisableBusEnumeration=TRUE. I can imagine that simply considering
PcdPciDisableBusEnumeration, and acting conditionally upon its value,
might solve these problems.

Thanks!
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

[Laszlo Ersek]

Including Igor & MST

Thanks
Laszlo

On 02/02/16 17:31, Kevin O'Connor wrote:
> On Tue, Feb 02, 2016 at 09:56:20AM +0100, Gerd Hoffmann wrote:
>>   Hi,
>>
 I'd have qemu copy the data on 0xfc write then, so things continue to
 work without updating seabios.  So, the firmware has to allocate space,
 reserve it etc.,  and programming the 0xfc register.  Qemu has to make
 sure the opregion appears at the address written by the firmware, by
 whatever method it prefers.
>>>
>>> Yup. It's Qemu's responsibility to expose opregion content. 
>>>
>>> btw, prefer to do copying here. It's pointless to allow write from guest
>>> side. One write example is SWSCI mailbox, thru which gfx driver can
>>> trigger some SCI event to communicate with BIOS (specifically ACPI
>>> methods here), mostly for some monitor operations. However it's 
>>> not a right thing for guest to trigger host SCI and thus kick host 
>>> ACPI methods.
>>
>> Thanks.
>>
>> So, question again how we do that best.  Option one being the mmap way,
>> i.e. basically what the patches posted by alex are doing.  Option two
>> being the fw_cfg way, i.e. place a opregion copy in fw_cfg and have
>> seabios not only set 0xfc, but also store the opregion there by copying
>> from fw_cfg.
> 
> What about option 2a - SeaBIOS copies from fw_cfg to memory and then
> programs 0xfc.  QEMU can detect the write to 0xfc and choose to map
> that ram (thus completely ignoring the contents that were just copied
> in) or it can choose not to map that ram (thus guest uses the contents
> just copied in).
> 
> The advantage of this approach is that it is a bit simpler in the
> firmware (no size probing is needed as the size comes from fw_cfg) and
> it allows for future flexibility as the choice of mapping can be
> deferred.
> 
> Totally untested seabios code below as example.
> 
> As an aside, if this type of "program a pci register" with a memory
> address becomes common, we could enhance the acpi-style "linker
> script" system to automate this..
> 
> -Kevin
> 
> 
> static void intel_igd_opregion_setup(struct pci_device *dev, void *arg)
> {
> struct romfile_s *file = romfile_find("etc/igd-opregion");
> if (!file)
> return;
> void *data = memalign_high(PAGE_SIZE, file->size);
> if (!data) {
> warn_noalloc();
> return;
> }
> int ret = file->copy(file, data, file->size);
> if (ret < 0) {
> free(data);
> return;
> }
> pci_config_writel(dev->bdf, 0xFC, (u32)data);
> }
> 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [SeaBIOS] [SEABIOS] Plans for either 1.9.1 or 1.10.0?

[Laszlo Ersek]

On 01/14/16 17:36, Gerd Hoffmann wrote:
> On Do, 2016-01-14 at 14:50 +, Ian Campbell wrote:
>> Hello,
>>
>> The xen.git development branch currently points to SeaBIOS rel-1.9.0, but
>> Roger has tripped over a build issue which is fixed by 3b8c5378dfe2 "build:
>> fix typo in buildversion.py".
>>
>> Is there any plan for either a 1.9.1 or a 1.10.0 in the near future which
>> would include this, so I can roll forward to that?
> 
> 1.10 will take a while ...
> 
>> Or if not a 1.9.1 release perhaps for now just a 1.9-stable branch could be
>> created?
> 
> 1.9-stable created now, with the patch above cherry-picked.
> 
> Doing 1.9.1 soonish (next week maybe) is fine with me.  If someone would
> like to see other patches backported to 1.9-stable please speak up now.

It's been suggested (by you :)) that
76327b9f32a009245c215f4a3c5d58a01b5310ae be cherry-picked into 1.9.1 as
well, perhaps.

Just raising it here, should you have forgotten. Also copying Marcel.

Thanks
Laszlo


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] [PATCH v2] OvmfPkg: XenPvBlkDxe: handle empty cdrom drives

[Laszlo Ersek]

On 10/21/15 13:39, Stefano Stabellini wrote:
> Empty cdroms are not going to connect, avoid waiting for the backend to
> switch to state 4, which is never going to happen, and return
> error instead from XenPvBlockFrontInitialization(). Detect an
> empty cdrom by looking at the "params" node on xenstore, which is set to
> "" or "aio:" for empty drives by libxl.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
> 
> ---
> Changes in v2:
> - better commit message
> - return EFI_DEVICE_ERROR instead of EFI_NO_MEDIA
> - check the return status of XenBusIo->XsBackendRead
> ---
>  OvmfPkg/XenPvBlkDxe/BlockFront.c |   15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/OvmfPkg/XenPvBlkDxe/BlockFront.c 
> b/OvmfPkg/XenPvBlkDxe/BlockFront.c
> index 256ac55..d07e980 100644
> --- a/OvmfPkg/XenPvBlkDxe/BlockFront.c
> +++ b/OvmfPkg/XenPvBlkDxe/BlockFront.c
> @@ -169,6 +169,7 @@ XenPvBlockFrontInitialization (
>XEN_BLOCK_FRONT_DEVICE *Dev;
>XenbusState State;
>UINT64 Value;
> +  CHAR8 *Params;
>  
>ASSERT (NodeName != NULL);
>  
> @@ -186,6 +187,20 @@ XenPvBlockFrontInitialization (
>}
>FreePool (DeviceType);
>  
> +  if (Dev->MediaInfo.CdRom) {
> +Status = XenBusIo->XsBackendRead (XenBusIo, XST_NIL, "params", 
> (VOID**));
> +if (Status != XENSTORE_STATUS_SUCCESS) {
> +  DEBUG ((EFI_D_ERROR, "%a: Failed to read params (%d)\n", __FUNCTION__, 
> Status));
> +  goto Error;
> +}
> +if (AsciiStrLen (Params) == 0 || AsciiStrCmp (Params, "aio:") == 0) {
> +  FreePool (Params);
> +  DEBUG ((EFI_D_INFO, "%a: Empty cdrom\n", __FUNCTION__));
> +  goto Error;
> +}
> +FreePool (Params);
> +  }
> +
>Status = XenBusReadUint64 (XenBusIo, "backend-id", FALSE, );
>if (Status != XENSTORE_STATUS_SUCCESS || Value > MAX_UINT16) {
>  DEBUG ((EFI_D_ERROR, "XenPvBlk: Failed to get backend-id (%d)\n",
> 

Reviewed-by: Laszlo Ersek <ler...@redhat.com>

I test-built this for X64 and Ia32, and then committed it to SVN as rev
18651.

Thanks!
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Laszlo Ersek]

On 10/20/15 13:59, Stefano Stabellini wrote:
> On Mon, 19 Oct 2015, Laszlo Ersek wrote:
>> On 10/16/15 21:09, Laszlo Ersek wrote:
>>> On 10/16/15 13:34, Fabio Fantoni wrote:
>>>> Il 16/10/2015 12:47, Stefano Stabellini ha scritto:
>>>>> On Fri, 16 Oct 2015, Fabio Fantoni wrote:
>>>>>> Il 16/10/2015 12:13, Anthony PERARD ha scritto:
>>>>>>> On Fri, Oct 16, 2015 at 10:32:44AM +0200, Fabio Fantoni wrote:
>>>>>>>> Il 15/10/2015 20:02, Anthony PERARD ha scritto:
>>>>>>>>> On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote:
>>>>>>>>>> Il 14/10/2015 13:06, Stefano Stabellini ha scritto:
>>>>>>>>>>> I would suggest Fabio to avoid AHCI disks altogether and just use
>>>>>>>>>>> OVMF
>>>>>>>>>>> with PV disks only and Anthony's patch to libxl to avoid creating
>>>>>>>>>>> any
>>>>>>>>>>> IDE disks: http://marc.info/?l=xen-devel=144482080812353.
>>>>>>>>>>>
>>>>>>>>>>> Would that work for you?
>>>>>>>>>> Thanks for the advice, I tried it:
>>>>>>>>>> https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6
>>>>>>>>>>
>>>>>>>>>> I installed W10 pro 64 bit with ide disk, installed the win pv
>>>>>>>>>> drivers
>>>>>>>>>> and
>>>>>>>>>> after changed to xvdX instead hdX, is the only change needed, right?
>>>>>>>>>> Initial boot is ok (ovmf part about pv disks seems ok) but windows
>>>>>>>>>> boot
>>>>>>>>>> fails with problem with pv drivers.
>>>>>>>>>> In attachment full qemu log with xen_platform trace and domU's xl
>>>>>>>>>> cfg.
>>>>>>>>>>
>>>>>>>>>> Someone have windows domUs with ovmf and pv disks only working?
>>>>>>>>>> If yes
>>>>>>>>>> can
>>>>>>>>>> tell me the difference to understand what can be the problem please?
>>>>>>>>> When I worked on the PV disk implementation in OVMF, I was able to
>>>>>>>>> boot
>>>>>>>>> a Windows 8 with pv disk only.
>>>>>>>>>
>>>>>>>>> I don't have access to the guest configuration I was using, but I
>>>>>>>>> think
>>>>>>>>> one
>>>>>>>>> difference would be the viridian setting, I'm pretty sure I did
>>>>>>>>> not set
>>>>>>>>> it.
>>>>>>>>>
>>>>>>>> I tried with viridian disabled but did the same thing, looking
>>>>>>>> cdrom as
>>>>>>>> latest thing before xenbug trace in qemu log I tried also to remove
>>>>>>>> it but
>>>>>>>> also in this case don't boot correctly, full qemu log in attachment.
>>>>>>>> I don't know if is a ovmf thing to improve (like what seems in
>>>>>>>> Laszlo and
>>>>>>>> Kevin mails) or xen winpv drivers unexpected case, have you tried also
>>>>>>>> with
>>>>>>>> latest winpv builds? (for exclude regression)
>>>>>>> No, I did not tried the latest winpv drivers.
>>>>>>>
>>>>>>> Sorry I can help much more that that. When I install this win8 guest
>>>>>>> tried
>>>>>>> to boot it with pv drivers only, that was more than a year ago. I
>>>>>>> have not
>>>>>>> check if it's still working. (Also I can not try anything more recent,
>>>>>>> right now.)
>>>>>>>
>>>>>> I did many other tests, retrying with ide first boot working but show pv
>>>>>> devices not working, I did another reboot (with ide) and pv devices was
>>>>>> working, after I retried with pv (xvdX) and boot correctly.
>>>>>> After other tests I found that with empty cdrom device (required for xl
>>>>>> cd-insert/cd-eject) boot stop at start (tianocore image), same result
>>>>>

Re: [Xen-devel] [PATCH] XenPvBlk: handle empty cdrom drives

[Laszlo Ersek]

(1) Please make the subject line say:

  OvmfPkg: XenPvBlkDxe: handle empty cdrom drives

On 10/20/15 17:03, Stefano Stabellini wrote:
> Empty cdroms are not going to connect, avoid waiting for the backend to
> switch to state 4, which is never going to happen, and return
> EFI_NO_MEDIA instead.

(2) I suggest to name the function here that should return EFI_NO_MEDIA
-- XenPvBlockFrontInitialization().

(3) Because the return status will ultimately be forwarded outside by
the driver binding's Start() function, if possible we should stick with
status codes listed by the UEFI spec. The relevant section is

  10.1 EFI Driver Binding Protocol
  EFI_DRIVER_BINDING_PROTOCOL.Start()

So, as long as we are setting the error code manually in
XenPvBlockFrontInitialization() -- ie. not propagating an error code
from another function we call there --, I think we should stick with
EFI_DEVICE_ERROR.

Sorry that I didn't point this out in my earlier message on qemu-devel.

> Detect an empty cdrom by looking at the "params"
> node on xenstore, which is set to  "" or "aio:" for empty drives by libxl.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Stefano Stabellini 
> 
> diff --git a/OvmfPkg/XenPvBlkDxe/BlockFront.c 
> b/OvmfPkg/XenPvBlkDxe/BlockFront.c
> index 256ac55..5a52a03 100644
> --- a/OvmfPkg/XenPvBlkDxe/BlockFront.c
> +++ b/OvmfPkg/XenPvBlkDxe/BlockFront.c
> @@ -169,6 +169,8 @@ XenPvBlockFrontInitialization (
>XEN_BLOCK_FRONT_DEVICE *Dev;
>XenbusState State;
>UINT64 Value;
> +  EFI_STATUS Ret = EFI_DEVICE_ERROR;

So this shouldn't be necessary.

(As a side point I'll mention that initialization of variables with
automatic storage duration is forbidden by the edk2 coding style;
separate assignments are required. I'm aware that this file already
doesn't comply with that, but that's no excuse. :))

> +  CHAR8 *Params;
>  
>ASSERT (NodeName != NULL);
>  
> @@ -186,6 +188,17 @@ XenPvBlockFrontInitialization (
>}
>FreePool (DeviceType);
>  
> +  if (Dev->MediaInfo.CdRom) {
> +XenBusIo->XsBackendRead (XenBusIo, XST_NIL, "params", (VOID**));
> +if (AsciiStrLen (Params) == 0 || AsciiStrCmp (Params, "aio:") == 0) {

(4) Please verify that XsBackendRead() returns XENSTORE_STATUS_SUCCESS.
I think you can use the "Status" variable for that.

If the read fails, you should assume one of "cdrom empty" vs. "cdrom not
empty" -- your call.

... I briefly considered that maybe XsBackendRead() is guaranteed to set
*Params to \0 on failure, but the typedef docs of the protocol member
function in question (XENBUS_XS_BACKEND_READ in
"OvmfPkg/Include/Protocol/XenBus.h") don't seem to guarantee that, so
please check the return status.

> +  FreePool (Params);
> +  DEBUG ((EFI_D_INFO, "XenPvBlk: Empty cdrom\n"));

(5) If this is a normal / expected condition, then EFI_D_INFO is fine.
If it is a genuine error, then EFI_D_ERROR should be used. I think
EFI_D_INFO is right though.

(6) Suggest to replace "XenPvBlk" with the "%a" conversion
specification, and pass in __FUNCTION__ as its argument. ("%a" formats
CHAR8 strings, while "%s" formats CHAR16 strings.)

__FUNCTION__ will expand to "XenPvBlockFrontInitialization", which is
both telling, and allows people with ctags- or cscope-compatible editors
to jump to the function immediately.

> +  Ret = EFI_NO_MEDIA;
> +  goto Error;

See (3) -- I think the goto suffices.

> +}
> +FreePool (Params);
> +  }
> +
>Status = XenBusReadUint64 (XenBusIo, "backend-id", FALSE, );
>if (Status != XENSTORE_STATUS_SUCCESS || Value > MAX_UINT16) {
>  DEBUG ((EFI_D_ERROR, "XenPvBlk: Failed to get backend-id (%d)\n",
> @@ -318,7 +331,7 @@ AbortTransaction:
>XenBusIo->XsTransactionEnd (XenBusIo, , TRUE);
>  Error:
>XenPvBlockFree (Dev);
> -  return EFI_DEVICE_ERROR;
> +  return Ret;
>  }
>  
>  VOID
> 

See (3) again.

I'm looking forward to version 2.

Thanks!
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Laszlo Ersek]

On 10/16/15 21:09, Laszlo Ersek wrote:
> On 10/16/15 13:34, Fabio Fantoni wrote:
>> Il 16/10/2015 12:47, Stefano Stabellini ha scritto:
>>> On Fri, 16 Oct 2015, Fabio Fantoni wrote:
>>>> Il 16/10/2015 12:13, Anthony PERARD ha scritto:
>>>>> On Fri, Oct 16, 2015 at 10:32:44AM +0200, Fabio Fantoni wrote:
>>>>>> Il 15/10/2015 20:02, Anthony PERARD ha scritto:
>>>>>>> On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote:
>>>>>>>> Il 14/10/2015 13:06, Stefano Stabellini ha scritto:
>>>>>>>>> I would suggest Fabio to avoid AHCI disks altogether and just use
>>>>>>>>> OVMF
>>>>>>>>> with PV disks only and Anthony's patch to libxl to avoid creating
>>>>>>>>> any
>>>>>>>>> IDE disks: http://marc.info/?l=xen-devel=144482080812353.
>>>>>>>>>
>>>>>>>>> Would that work for you?
>>>>>>>> Thanks for the advice, I tried it:
>>>>>>>> https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6
>>>>>>>>
>>>>>>>> I installed W10 pro 64 bit with ide disk, installed the win pv
>>>>>>>> drivers
>>>>>>>> and
>>>>>>>> after changed to xvdX instead hdX, is the only change needed, right?
>>>>>>>> Initial boot is ok (ovmf part about pv disks seems ok) but windows
>>>>>>>> boot
>>>>>>>> fails with problem with pv drivers.
>>>>>>>> In attachment full qemu log with xen_platform trace and domU's xl
>>>>>>>> cfg.
>>>>>>>>
>>>>>>>> Someone have windows domUs with ovmf and pv disks only working?
>>>>>>>> If yes
>>>>>>>> can
>>>>>>>> tell me the difference to understand what can be the problem please?
>>>>>>> When I worked on the PV disk implementation in OVMF, I was able to
>>>>>>> boot
>>>>>>> a Windows 8 with pv disk only.
>>>>>>>
>>>>>>> I don't have access to the guest configuration I was using, but I
>>>>>>> think
>>>>>>> one
>>>>>>> difference would be the viridian setting, I'm pretty sure I did
>>>>>>> not set
>>>>>>> it.
>>>>>>>
>>>>>> I tried with viridian disabled but did the same thing, looking
>>>>>> cdrom as
>>>>>> latest thing before xenbug trace in qemu log I tried also to remove
>>>>>> it but
>>>>>> also in this case don't boot correctly, full qemu log in attachment.
>>>>>> I don't know if is a ovmf thing to improve (like what seems in
>>>>>> Laszlo and
>>>>>> Kevin mails) or xen winpv drivers unexpected case, have you tried also
>>>>>> with
>>>>>> latest winpv builds? (for exclude regression)
>>>>> No, I did not tried the latest winpv drivers.
>>>>>
>>>>> Sorry I can help much more that that. When I install this win8 guest
>>>>> tried
>>>>> to boot it with pv drivers only, that was more than a year ago. I
>>>>> have not
>>>>> check if it's still working. (Also I can not try anything more recent,
>>>>> right now.)
>>>>>
>>>> I did many other tests, retrying with ide first boot working but show pv
>>>> devices not working, I did another reboot (with ide) and pv devices was
>>>> working, after I retried with pv (xvdX) and boot correctly.
>>>> After other tests I found that with empty cdrom device (required for xl
>>>> cd-insert/cd-eject) boot stop at start (tianocore image), same result
>>>> with ide
>>>> instead.
>>>>  From xl cfg:
>>>> disk=['/mnt/vm/disks/W10UEFI.disk1.cow-sn1,qcow2,xvda,rw',',raw,xvdb,ro,cdrom']
>>>>
>>>> With seabios domU boot also with empty cdrom.
>>>> In qemu log I found only these that can be related:
>>>>> xen be: qdisk-51728: error: Could not open image: No such file or
>>>>> directory
>>>>> xen be: qdisk-51728: initialise() failed
>>>> And latest xl dmesg line is:
>>>>> (d1) Invoking OVMF ...
>>>> If you need more informations/test tell 

Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Laszlo Ersek]

On 10/19/15 20:29, Fabio Fantoni wrote:
> 2015-10-19 18:57 GMT+02:00 Stefano Stabellini
>  >:
> 
> On Mon, 19 Oct 2015, John Snow wrote:
> > On 10/19/2015 07:44 AM, Stefano Stabellini wrote:
> > > On Mon, 19 Oct 2015, Gerd Hoffmann wrote:
> > >>   Hi,
> > >>
> >  I'm trying to follow this discussion as best as I am able,
> but my lack
> >  of experience with Xen prevents me from really participating in a
> >  meaningful way.
> > 
> >  (I see that Laszlo is still discussing some CD-ROM issues
> with Fabio
> >  which may be of interest to me...)
> > 
> >  At any rate, I won't be authoring any Xen-specific hacks to
> the AHCI
> >  device, but I do have plans to implement hot-plugging
> emulation as per
> >  the AHCI spec. Perhaps this is sufficient for the Xen layer,
> but someone
> >  else will need to author the appropriate glue code.
> > 
> >  If "real" hot-plugging is not sufficient, we'll need to
> discuss further,
> >  preferably over some RFC patches.
> > >>>
> > >>> That's fine. AHCI hot-plugging would go a long way and once we
> have
> > >>> that, the rest is easy.
> > >>
> > >> Can we get some more background on this?
> > >>
> > >> IIRC the IDE bits are needed to boot hvm guests, which goes
> like this:
> > >>
> > >>   (1) boot disk is hooked up using both xenbus and ide.
> > >>   (2) seabios boots using ide.
> > >>   (3) linux kernel activates xenbus, at which point qemu zaps
> the ide
> > >>   disks to avoid the disk being present twice in the system.
> > >>
> > >> Correct?
> > >>
> > >> Do we really want repeat this exercise for AHCI?  Alot has
> changed since
> > >> this boot hack for ide was added ...
> > >>
> > >> As far I know OVMF has xenbus drivers, so OVMF should already
> boot xen
> > >> guests just fine without this, correct?
> > >
> > > I agree with you that the current unplug in nasty. Also I don't care
> > > much about AHCI, in fact I don't think we should be spending efforts
> > > into making that scenario work better. I think we should be
> working on
> > > OVMF instead and fix the bug about empty cdrom drives reported
> by Fabio.
> > >
> >
> > OVMF and AHCI go hand in hand here from my viewpoint. I'm happy to
> debug
> > any OVMF+SATA/AHCI problems that are reported.
> >
> > Last I saw, Laszlo asked Fabio for some more information on this
> > problem, so I am waiting for that information to start work on
> that issue.
> 
> Fabio reported a bug using OVFM+xen_disk, no AHCI involved. OVFM has
> already support for the Xen PV disk protocol, see
> OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.c.
> 
> 
> I not tried with ahci in ovmf in latest because as you told that is a
> missing unplug case in qemu.
> 
> I tried with xendisk and ide, the empty cdrom problem is with both, from
> xl domU cfg:
> 
> ',raw,xvdb,ro,cdrom' for xendisk and ',raw,hdb,ro,cdrom' for ide.
> 
> Using seabios instead boot correctly, with ovmf not:
> http://lists.xen.org/archives/html/xen-devel/2015-10/msg01833.html

I'll reply in that thread soon, with more info I might have.

> If I remember good also in latest test persist also the problem that ovmf not 
> respect the boot order parameter.

OVMF has *utter* respect for the boot order that comes from QEMU via
fw_cfg. The code that is in place has taken many-many hours, and it's
one of the major features of OVMF.

You are welcome to review both the code / git history:

  OvmfPkg/Library/QemuBootOrderLib/

and its extensive documentation:

  http://www.linux-kvm.org/page/OVMF
  (the OVMF whitepaper)

  section "Platform-specific boot policy"

The topic is complex, which is why it requires elaborate code, and
similarly elaborate documentation. The code works in ARM guests as well
(QEMU or KVM), and has been repeatedly updated to recognize QEMU's
OpenFirmware device paths for more and more device types. (Most recently
in .)

The library doesn't work in Xen guests for two reasons:
- I'm not a Xen developer,
- no Xen developer has contributed patches for boot order processing on
  Xen. (If you are interested, *please* read the whitepaper section
  above, before asking questions.)

The immediate technical reason is that Xen guests don't have an fw_cfg
device.

Thanks
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Laszlo Ersek]

On 10/16/15 13:34, Fabio Fantoni wrote:
> Il 16/10/2015 12:47, Stefano Stabellini ha scritto:
>> On Fri, 16 Oct 2015, Fabio Fantoni wrote:
>>> Il 16/10/2015 12:13, Anthony PERARD ha scritto:
 On Fri, Oct 16, 2015 at 10:32:44AM +0200, Fabio Fantoni wrote:
> Il 15/10/2015 20:02, Anthony PERARD ha scritto:
>> On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote:
>>> Il 14/10/2015 13:06, Stefano Stabellini ha scritto:
 I would suggest Fabio to avoid AHCI disks altogether and just use
 OVMF
 with PV disks only and Anthony's patch to libxl to avoid creating
 any
 IDE disks: http://marc.info/?l=xen-devel=144482080812353.

 Would that work for you?
>>> Thanks for the advice, I tried it:
>>> https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6
>>>
>>> I installed W10 pro 64 bit with ide disk, installed the win pv
>>> drivers
>>> and
>>> after changed to xvdX instead hdX, is the only change needed, right?
>>> Initial boot is ok (ovmf part about pv disks seems ok) but windows
>>> boot
>>> fails with problem with pv drivers.
>>> In attachment full qemu log with xen_platform trace and domU's xl
>>> cfg.
>>>
>>> Someone have windows domUs with ovmf and pv disks only working?
>>> If yes
>>> can
>>> tell me the difference to understand what can be the problem please?
>> When I worked on the PV disk implementation in OVMF, I was able to
>> boot
>> a Windows 8 with pv disk only.
>>
>> I don't have access to the guest configuration I was using, but I
>> think
>> one
>> difference would be the viridian setting, I'm pretty sure I did
>> not set
>> it.
>>
> I tried with viridian disabled but did the same thing, looking
> cdrom as
> latest thing before xenbug trace in qemu log I tried also to remove
> it but
> also in this case don't boot correctly, full qemu log in attachment.
> I don't know if is a ovmf thing to improve (like what seems in
> Laszlo and
> Kevin mails) or xen winpv drivers unexpected case, have you tried also
> with
> latest winpv builds? (for exclude regression)
 No, I did not tried the latest winpv drivers.

 Sorry I can help much more that that. When I install this win8 guest
 tried
 to boot it with pv drivers only, that was more than a year ago. I
 have not
 check if it's still working. (Also I can not try anything more recent,
 right now.)

>>> I did many other tests, retrying with ide first boot working but show pv
>>> devices not working, I did another reboot (with ide) and pv devices was
>>> working, after I retried with pv (xvdX) and boot correctly.
>>> After other tests I found that with empty cdrom device (required for xl
>>> cd-insert/cd-eject) boot stop at start (tianocore image), same result
>>> with ide
>>> instead.
>>>  From xl cfg:
>>> disk=['/mnt/vm/disks/W10UEFI.disk1.cow-sn1,qcow2,xvda,rw',',raw,xvdb,ro,cdrom']
>>>
>>> With seabios domU boot also with empty cdrom.
>>> In qemu log I found only these that can be related:
 xen be: qdisk-51728: error: Could not open image: No such file or
 directory
 xen be: qdisk-51728: initialise() failed
>>> And latest xl dmesg line is:
 (d1) Invoking OVMF ...
>>> If you need more informations/test tell me and I'll post them.
>> Are you saying that without any cdrom drives, it works correctly?
> Yes, I did also another test to be sure, starting with ide, installing
> windows, the pv drivers, rebooting 2 times (with one at boot of time
> boot with ide only and without net and disks pv drivers working) and
> after rebooting with pv disks (xvdX) works.
> With cdrom not empty (with iso) works, with empty not, tried with both
> ide (hdX) and pv (xvdX).
> Empty cdrom not working with ovmf I suppose is ovmf bug or inexpected case.
> About major of winpv drivers problem at boot I suppose can be solved
> improving ovmf and winpv driver removing bad hybrid thing actually, but
> I have too low knowledge to be sure.
> About the problem of pv start after install that requiring at least 2
> reboot can be also a windows 10 problem (only a suppose).
> 
> About empty cdrom with ovmf can be solved please?
> 

Sorry, I find your problem report impenetrable. :( Please slow down and
try to spend time on punctuation at least.

For me to make heads or tails of this, I'll need the following:

- The debug output of an OVMF binary built with the DEBUG_VERBOSE bit
(0x0040) enabled in PcdDebugPrintErrorLevel, in addition to the
default setting.

- Preferably, I'll need two logs, one for the "working" case, and
another for the "non-working" case.

- A description of the virtual hardware (disks etc) that is
understandable to someone who hasn't booted Xen in several years; for
both cases above.

- Please try to make an exact, itemized list of the steps you perform
before executing the successful vs. 

Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Laszlo Ersek]

On 10/16/15 11:06, Stefano Stabellini wrote:
> On Thu, 15 Oct 2015, Kevin O'Connor wrote:
>> On Fri, Oct 16, 2015 at 01:10:54AM +0200, Laszlo Ersek wrote:
>>> On 10/14/15 13:27, Ian Campbell wrote:
>>>> On Wed, 2015-10-14 at 12:06 +0100, Stefano Stabellini wrote:
>>>>>> Can't you just teach SeaBIOS how to deal with your PV disks and then
>>>>>> only add that to your VM and forget about IDE/AHCI? I mean, that's how
>>>>>> it's done for virtio-blk, and it doesn't involve any insanities like
>>>>>> ripping out non-hotpluggable devices.
>>>>>
>>>>> Teaching SeaBIOS to deal with PV disks can be done, in fact we already
>>>>> support PV disks in OVMF. It is possible to boot Windows with OVMF
>>>>> without any IDE disks (patch pending for libxl to create a VM without
>>>>> emulated IDE disks).
>>>>
>>>> One stumbling block in the past has been how to know when the PV drivers in
>>>> the BIOS are no longer required, such that the ring can be torn down and/or
>>>> the connection etc handed over to the OS driver.
>> [...]
>>>> AFAIK the BIOS interfaces do not have anything as reliable as that.
>>>>
>>>> How does virtio deal with this in the BIOS case?
>>>
>>> It doesn't, as far as I can tell.
>>>
>>> I don't think it has to, though! On a BIOS box, you can always boot DOS,
>>> or another operating system that continues to use the BIOS interfaces
>>> forever. (Same as if you never call ExitBootServices() in UEFI.)
>>>
>>> Given that no starter pistol gets fired between the firmware and the OS
>>> on such a platform, they must always respect each other. I guess this
>>> could occur through the E820 map, or some such.
>>
>> One can use the "ACPI enable" SMI event to detect this if they really
>> wanted to.  In SeaBIOS one could do this from
>> src/fw/smm.c:handle_smi() - however, no other drivers need this
>> notification today and it would be a bit ugly to have to handle it
>> from an SMI.  (Assuming Xen were to support SMIs.)
>>
>>> No clue in what kind of E820 memory SeaBIOS allocates the virtio rings,
>>> but I guess the Linux kernel stays away from those areas until it's past
>>> device probing and binding.
>>
>> In SeaBIOS, the virtio memory is allocated from reserved memory.  (See
>> the memalign_high() call in src/hw/virtio-pci.c - the "high" memory
>> zone is taken from reserved memory:
>> http://seabios.org/Memory_Model#Memory_available_during_initialization
>> )
>>
>> What's the reason for the "stumbling block" that requires the BIOS to
>> tear down the Xen ring prior to the OS being able to replace it?  The
>> BIOS disk calls are all synchronous, so the ring wont be active when
>> the OS brings up its own ring.  Is there some low-level interaction
>> that prevents the OS from just resetting the ring prior to enabling
>> it?
> 
> Xen only exports one PV disk interface for each disk to the guest, and
> each PV interface only supports one frontend -- only SeaBIOS or the OS
> can be connected to one PV disk, not both. In the case of OVMF, we
> handle that by disconnecting the PV frontend in OVMF when
> ExitBootServices is called, so that the OS driver can reconnect later.

Does the XenBus protocol support a device reset operation, regardless of
what state the device is currently in? (I don't remember all the state
transitions any longer, sorry.)

Thanks
Laszlo


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Laszlo Ersek]

On 10/16/15 04:38, Kevin O'Connor wrote:
> On Fri, Oct 16, 2015 at 01:10:54AM +0200, Laszlo Ersek wrote:
>> On 10/14/15 13:27, Ian Campbell wrote:
>>> On Wed, 2015-10-14 at 12:06 +0100, Stefano Stabellini wrote:
>>>>> Can't you just teach SeaBIOS how to deal with your PV disks and then
>>>>> only add that to your VM and forget about IDE/AHCI? I mean, that's how
>>>>> it's done for virtio-blk, and it doesn't involve any insanities like
>>>>> ripping out non-hotpluggable devices.
>>>>
>>>> Teaching SeaBIOS to deal with PV disks can be done, in fact we already
>>>> support PV disks in OVMF. It is possible to boot Windows with OVMF
>>>> without any IDE disks (patch pending for libxl to create a VM without
>>>> emulated IDE disks).
>>>
>>> One stumbling block in the past has been how to know when the PV drivers in
>>> the BIOS are no longer required, such that the ring can be torn down and/or
>>> the connection etc handed over to the OS driver.
> [...]
>>> AFAIK the BIOS interfaces do not have anything as reliable as that.
>>>
>>> How does virtio deal with this in the BIOS case?
>>
>> It doesn't, as far as I can tell.
>>
>> I don't think it has to, though! On a BIOS box, you can always boot DOS,
>> or another operating system that continues to use the BIOS interfaces
>> forever. (Same as if you never call ExitBootServices() in UEFI.)
>>
>> Given that no starter pistol gets fired between the firmware and the OS
>> on such a platform, they must always respect each other. I guess this
>> could occur through the E820 map, or some such.
> 
> One can use the "ACPI enable" SMI event to detect this if they really
> wanted to.  In SeaBIOS one could do this from
> src/fw/smm.c:handle_smi() - however, no other drivers need this
> notification today and it would be a bit ugly to have to handle it
> from an SMI.  (Assuming Xen were to support SMIs.)
> 
>> No clue in what kind of E820 memory SeaBIOS allocates the virtio rings,
>> but I guess the Linux kernel stays away from those areas until it's past
>> device probing and binding.
> 
> In SeaBIOS, the virtio memory is allocated from reserved memory.

Perfect! That gives Xen drivers precedence to do the same.

>  (See
> the memalign_high() call in src/hw/virtio-pci.c - the "high" memory
> zone is taken from reserved memory:
> http://seabios.org/Memory_Model#Memory_available_during_initialization
> )
> 
> What's the reason for the "stumbling block" that requires the BIOS to
> tear down the Xen ring prior to the OS being able to replace it?  The
> BIOS disk calls are all synchronous, so the ring wont be active when
> the OS brings up its own ring.

Yes, that's an argument that works well in practice. However...

> Is there some low-level interaction
> that prevents the OS from just resetting the ring prior to enabling
> it?

the assumption was that the ring would be placed into normal memory. If
GRUB or the kernel overwrote the memory (reallocating the same pages for
completely unrelated purposes) that used to contain the ring while
SeaBIOS was serving requests, the hypervisor would be allowed to notice
and act upon writes to those pages *without* any explicit "kick" (=
guest-to-host notification). The hypervisor is allowed to look at the
ring any time it wishes, so guest code uses barriers while populating
the ring, and kicks the hypervisor "just in case it's not looking right
now".

But if the firmware's ring is in reserved memory, then the OS will stay
away forever. That's great -- it answers the question for virtio, and
should also guide a Xen PV driver implementation.

Thanks!
Laszlo

> 
> -Kevin
> 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Laszlo Ersek]

On 10/14/15 14:48, Paul Durrant wrote:
>> -Original Message-
>> From: Fabio Fantoni [mailto:fabio.fant...@m2r.biz]
>> Sent: 14 October 2015 12:12
>> To: Kevin Wolf; Stefano Stabellini
>> Cc: John Snow; Anthony Perard; qemu-de...@nongnu.org; xen-
>> de...@lists.xen.org; qemu-bl...@nongnu.org; Paul Durrant
>> Subject: Re: [Qemu-devel] Question about xen disk unplug support for ahci
>> missed in qemu
>>
>>
>>
>> Il 14/10/2015 11:47, Kevin Wolf ha scritto:
>>> [ CC qemu-block ]
>>>
>>> Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben:
 On Tue, 13 Oct 2015, John Snow wrote:
> On 10/13/2015 11:55 AM, Fabio Fantoni wrote:
>> I added ahci disk support in libxl and using it for week seems that was
>> ok, after a reply of Stefano Stabellini seems that xen disk unplug
>> support only ide disks:
>>
>> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39
>> c905374ee8663d5d8
>>
>> Today Paul Durrant told me that even if pv disk is ok also with ahci and
>> the emulated one is offline can be a risk:
>> http://lists.xenproject.org/archives/html/win-pv-devel/2015-
>> 10/msg00021.html
>>
>>
>> I tried to take a fast look in qemu code but I not understand the
>> needed
>> thing for add the xen disk unplug support also for ahci, can someone do
>> it or tell me useful information for do it please?
>>
>> Thanks for any reply and sorry for my bad english.
>>
> I'm not entirely sure what features you need AHCI to support in order
> for Xen to be happy.
>
> I'd guess hotplugging, but where I get confused is that IDE disks don't
> support hotplugging either, so I guess I'm not sure sure what you need.
>
> Stefano, can you help bridge my Xen knowledge gap?

 Hi John,

 we need something like hw/i386/xen/xen_platform.c:unplug_disks but
>> that
 can unplug AHCI disk. And by unplug, I mean "make disappear" like
 pci_piix3_xen_ide_unplug does for ide.
>>> Maybe this would be the right time to stop the craziness with your
>>> hybrid IDE/xendisk setup. It's a horrible thing that would never happen
>>> on real hardware.
> 
> Unfortunately, it's going to be difficult to remove such 'craziness' when you 
> don't know a priori whether the VM has PV drivers or not. 
> 
>>>
>>> Can't you just teach SeaBIOS how to deal with your PV disks and then
>>> only add that to your VM and forget about IDE/AHCI? I mean, that's how
>>> it's done for virtio-blk, and it doesn't involve any insanities like
>>> ripping out non-hotpluggable devices.
>>>
> 
> Does Windows have in-box virtio-blk drivers? If not, how does it boot?

The firmwares have virtio drivers (SeaBIOS and OVMF). The Windows
installer can be booted far enough, on top of the firmware services,
that Windows explicitly asks for a driver disk -- not only for the
installation *target* disk, but even for the CD-ROM that it is being
installed *from*.

In practice, you can install modern Windows (Windows 8 and later
definitely, I *think* maybe even Windows 7), from a virtio-scsi CD-ROM,
to, say, a virtio-block disk, and provide *only* the virtio drivers on a
separate IDE CD-ROM (which you can later remove completely, on the
device level).

The Windows installer's boot loader loads an initial ramdisk into
memory, using firmware services. Then its kernel starts and has access
to a number of basic drivers, like IDE CD-ROM drivers. That is
sufficient to load the virtio-scsi driver from the virtio-win ISO, and
then the installation can continue from the original virtio-scsi CD-ROM.

I always install windows guests like this; it is quite flexible. (In
brief: 1 virtio-block target disk, 1 virtio-scsi CD-ROM holding the
Windows ISO, 1 IDE CD-ROM (to be removed permanently from the guest
config, later) holding the virtio-win driver ISO.)

> 
>>> Hm... How does a reboot of a machine that had its IDE already removed
>>> actually work? Do you restart the qemu process on reboot?
>>>
> 
> The IDE disks are always present during boot, but before the OS
> enumerates them they are 'unplugged' and then PV drivers are used
> instead.

Supporting this in RHEL-5 and RHEL-6 guests was *incredible* pain.

Also, when you consider kexec / kdump in the guest, that was an unending
source of bug reports. If I recall correctly, the PV devices (net and
block) could not be used by the kdump kernel, because the main (crashed)
kernel may have left them in a bad state (and I'm not sure if it was
possible to reinit them.) And the emulated devices were slow... assuming
the kdump kernel didn't try to unplug them first!

(Maybe Vitaly (CC'd) knows more about the current status in this area;
I'm admittedly fuzzy, sorry. My intent is not to spread FUD.)

(I'll also admit that running kdump in the guest (that's already
crashed) is a bad idea in general, given that the host is there right
under it, capable of dumping the guests memory without issues. Maybe not
so flexible for some 

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

[Laszlo Ersek]

On 09/14/15 11:22, Ian Campbell wrote:
> On Fri, 2015-09-11 at 17:28 +0200, Laszlo Ersek wrote:
>>
> [...]
>> For me that's not so clear-cut. OVMF is frequently used as a UEFI
>> development environment (it's better to brick a virtual machine than
>> your physical dev platform...)
> 
> One flip side to this is that people often virtualize in order to continue
> running their older platforms and applications, because upgrading them
> would be difficult for whatever reason.
> 
> There's an obvious tension between that and the desire to use OVMF as a
> development platform, but it seems to me that the developers are the ones
> who can more readily be expected to mess with the defaults.

Good points!

>> , so upstream should embrace new UEFI
>> features reasonably early, unless there are *grave* regressions.
>>
>> One example I named was the properties table feature (new in UEFI-2.5).
>> It would break Windows 7. Given the large number of users running
>> Windows 7 on OVMF (mainly for GPU passthrough), such a regression would
>> be serious.
>>
>> Breaking Debian Wheezy's and BITS's GRUB is also bad, but the former is
>> very old (and has a clear upgrade path)
> 
> Debian Wheezy is not very old, it's only a year older than RHEL7 (May 2013
> vs June 2014) and only a bit older than two years in absolute terms. It is
> also the subject of an LTS effort, which extends its lifetime to 2018.

(*)

> For comparison Windows 7 (which you argue regressing would be serious) was
> released in 2009 and there have been two major Windows releases since then.

(**)

> Given that and with consideration between the desire to run older platforms
> vs. a development environment it seems to me that Debian Wheezy has not yet
> reached the threshold for being ignored or for saying to users "you must
> now upgrade".

I believe I could argue against both (*) and (**), but it would not be
productive. :)

Instead, what matters is the (now) clear, significant user demand for
turning off PcdSetNxForStack by default. I'll send a followup patch for
my series to that end.

And, sorry about the inconvenience the regression may have caused, of
course ;)

Thanks!
Laszlo


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

[Laszlo Ersek]

On 09/12/15 01:06, Josh Triplett wrote:
> On Fri, Sep 11, 2015 at 11:27:32PM +0200, Laszlo Ersek wrote:
>> On 09/11/15 21:30, Josh Triplett wrote:
>>> On Fri, Sep 11, 2015 at 05:28:06PM +0200, Laszlo Ersek wrote:
>>>> Breaking Debian Wheezy's and BITS's GRUB is also bad, but the former is
>>>> very old (and has a clear upgrade path), while the latter is mainly used
>>>> by developers (who can learn about the -fw_cfg switch by googling or
>>>> asking on the least without huge trouble). In this case I'm leaning
>>>> towards OVMF being "bleeding edge" by default. But, I could be convinced
>>>> otherwise.
>>>
>>> I certainly think it makes sense for OVMF to adopt the feature sooner
>>> than normal, and I agree that OVMF serves as a test case.  But going
>>> directly from "not possible to turn on" to "turned on by default",
>>> without any period of "off by default but possible to turn on", seems a
>>> bit unfortunate.
>>>
>>> That said, we could certainly fix BITS to use newer GRUB2, and use
>>> (and document) -fw_cfg in the meantime.  So I won't push *too* hard for
>>> changing the default, just mildly.
>>
>> Okay. If I'll need to send a v2 for any reason, I'll incorporate this.
>> If not, then I can post a followup patch later (stating that it's due to
>> community feedback).
> 
> Thanks!
> 
>>> On a vaguely related note, what's the canonical place to report bugs in
>>> OVMF?
>>
>> (Bugs? What bugs? :))
>>
>> It's this list, <edk2-de...@lists.01.org>.
> 
> There isn't a tracker of some kind?  That's unfortunate.

I won't disagree with you, but I'll note three things:

(1) There isn't much use to a bug tracker if there aren't enough human
resources to actually monitor that tracker, and work hard on the bugs. I
can offer to monitor this list and work on bugs reported here the best I
can. Bug fixing is hard and taxing; for *official* long-term bug
tracking, some form of legal relationship is usually necessary. I do
take my RHBZs very seriously.

(2) OvmfPkg is one platform in edk2. I don't think OVMF / OvmfPkg should
have its own separate tracker. And regarding a tracker for the entirety
of edk2, there used to be one (still on sf.net), and nobody (no
contributor or maintainer) cared. Goto (1).

(3) I've seen first hand how Fedora bug tracker entries, Debian bug
tracker entries, and upstream QEMU bug tracker entries are handled. Goto
(1). As I said, I try to do my best with bugs reported on the list, both
in tracking them and in fixing them, as my load allows.

> But thanks; I'll send mail to the list when we discover an issue while
> experimenting with BITS.

Yes, please do that. And thank you. In my experience, other package
maintainers (not just us in OvmfPkg) are pretty responsive if you report
bugs for their packages on the list, especially if you can narrow it
down (bisection, good reproducer etc).

> 
> (Also, if you don't intend to use github's issue tracker, you might want
> to turn it off so people don't file things there and expect a response.)

That's a very good point. Jordan, can you please disable the issue
tracker on github?

Thanks
Laszlo

> 
> - Josh Triplett
> 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

[Laszlo Ersek]

On 09/11/15 21:30, Josh Triplett wrote:
> On Fri, Sep 11, 2015 at 05:28:06PM +0200, Laszlo Ersek wrote:
>> On 09/11/15 16:10, Josh Triplett wrote:
>>> On Fri, Sep 11, 2015 at 01:43:53PM +0200, Laszlo Ersek wrote:
>>>> On 09/09/15 12:48, Laszlo Ersek wrote:
>>>>> On 09/09/15 11:37, Ian Campbell wrote:
>>>>>> On Wed, 2015-09-09 at 01:06 -0600, Jan Beulich wrote:
>>>>>>>>>> On 09.09.15 at 00:23, <ler...@redhat.com> wrote:
>>>>>>>> On 09/08/15 19:26, Anthony PERARD wrote:
>>>>>>>>> And I get this on the console:
>>>>>>>>> Welcome to GRUB!
>>>>>>>>>
>>>>>>>>>  X64 Exception Type - 0E(#PF - Page-Fault)  CPU Apic ID -
>>>>>>>>>  
>>>>>>>>> RIP  - 0F5F8918, CS  - 0028, RFLAGS -
>>>>>>>>> 00210206
>>>>>>>>> ExceptionData - 0011
>>>>>>>>> RAX  - , RCX - 07FCE000, RDX -
>>>>>>>>> 
>>>>>>>>> RBX  - 0B6092C0, RSP - 0F5F8590, RBP -
>>>>>>>>> 0B608EA0
>>>>>>>>> RSI  - 0F5F8838, RDI - 0B608EA0
>>>>>>>>> R8   - , R9  - 0B609200, R10 -
>>>>>>>>> 
>>>>>>>>> R11  - 000A, R12 - , R13 -
>>>>>>>>> 001B
>>>>>>>>> R14  - 0B609360, R15 - 
>>>>>>>>> DS   - 0008, ES  - 0008, FS  -
>>>>>>>>> 0008
>>>>>>>>> GS   - 0008, SS  - 0008
>>>>>>>>> CR0  - 8033, CR2 - 0F5F8918, CR3 -
>>>>>>>>> 0F597000
>>>>>>>>> CR4  - 0668, CR8 - 
>>>>>>>>> DR0  - , DR1 - , DR2 -
>>>>>>>>> 
>>>>>>>>> DR3  - , DR6 - 0FF0, DR7 -
>>>>>>>>> 0400
>>>>>>>>> GDTR - 0F57BF18 003F, LDTR - 
>>>>>>>>> IDTR - 0EEA5018 0FFF,   TR - 
>>>>>>>>> FXSAVE_STATE - 0F5F81F0
>>>>>>>>>  Find PE image 
>>>>>>>> /build/xen-unstable/src/xen-unstable/tools/firmware/ovmf-dir
>>>>>>>> -remote/Build
>>>>>>>> /OvmfX64/DEBUG_GCC49/X64/IntelFrameworkModulePkg/Universal/StatusCode/R
>>>>>>>> untime
>>>>>>>> Dxe/StatusCodeRuntimeDxe/DEBUG/StatusCodeRuntimeDxe.dll 
>>>>>>>> (ImageBase=0F556000, EntryPoint=0F55628F) 
>>>>>>>>>
>>>>>>>>> I did check with other guest (Windows, Ubuntu, Debian Jessie), and
>>>>>>>>> they are
>>>>>>>>> working correctly. Debian Wheezy is the only one that fail.
>>>>>>>>
>>>>>>>> I don't have an environment to reproduce this in. I think we should try
>>>>>>>> to understand this problem better, before deciding how to make it go
>>>>>>>> away.
>>>>>>>>
>>>>>>>> Please locate the "StatusCodeRuntimeDxe.debug" file in your Build
>>>>>>>> directory (ie. under the location listed in the error report). Then,
>>>>>>>> please disassemble it with "objdump -S". The fault location in the
>>>>>>>> disassembly can be found based on RIP, ImageBase and EntryPoint;
>>>>>>>
>>>>>>> I don't think the exact instruction at that address really matters. The
>>>>>>> main question appears to be why RIP and RSP both point into the
>>>>>>> same page (see also the subject of Anthony's mail).
>>>>>>
>>>>>> I'm not 100% what is going on,
>>>>>
>>>>> me neither :)
>>>>>
>>>>>> but if this (executable code on stack) is
>>

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

[Laszlo Ersek]

On 09/09/15 12:48, Laszlo Ersek wrote:
> On 09/09/15 11:37, Ian Campbell wrote:
>> On Wed, 2015-09-09 at 01:06 -0600, Jan Beulich wrote:
>>>>>> On 09.09.15 at 00:23, <ler...@redhat.com> wrote:
>>>> On 09/08/15 19:26, Anthony PERARD wrote:
>>>>> And I get this on the console:
>>>>> Welcome to GRUB!
>>>>>
>>>>>  X64 Exception Type - 0E(#PF - Page-Fault)  CPU Apic ID -
>>>>>  
>>>>> RIP  - 0F5F8918, CS  - 0028, RFLAGS -
>>>>> 00210206
>>>>> ExceptionData - 0011
>>>>> RAX  - , RCX - 07FCE000, RDX -
>>>>> 
>>>>> RBX  - 0B6092C0, RSP - 0F5F8590, RBP -
>>>>> 0B608EA0
>>>>> RSI  - 0F5F8838, RDI - 0B608EA0
>>>>> R8   - , R9  - 0B609200, R10 -
>>>>> 
>>>>> R11  - 000A, R12 - , R13 -
>>>>> 001B
>>>>> R14  - 0B609360, R15 - 
>>>>> DS   - 0008, ES  - 0008, FS  -
>>>>> 0008
>>>>> GS   - 0008, SS  - 0008
>>>>> CR0  - 8033, CR2 - 0F5F8918, CR3 -
>>>>> 0F597000
>>>>> CR4  - 0668, CR8 - 
>>>>> DR0  - , DR1 - , DR2 -
>>>>> 
>>>>> DR3  - , DR6 - 0FF0, DR7 -
>>>>> 0400
>>>>> GDTR - 0F57BF18 003F, LDTR - 
>>>>> IDTR - 0EEA5018 0FFF,   TR - 
>>>>> FXSAVE_STATE - 0F5F81F0
>>>>>  Find PE image 
>>>> /build/xen-unstable/src/xen-unstable/tools/firmware/ovmf-dir
>>>> -remote/Build
>>>> /OvmfX64/DEBUG_GCC49/X64/IntelFrameworkModulePkg/Universal/StatusCode/R
>>>> untime
>>>> Dxe/StatusCodeRuntimeDxe/DEBUG/StatusCodeRuntimeDxe.dll 
>>>> (ImageBase=0F556000, EntryPoint=0F55628F) 
>>>>>
>>>>> I did check with other guest (Windows, Ubuntu, Debian Jessie), and
>>>>> they are
>>>>> working correctly. Debian Wheezy is the only one that fail.
>>>>
>>>> I don't have an environment to reproduce this in. I think we should try
>>>> to understand this problem better, before deciding how to make it go
>>>> away.
>>>>
>>>> Please locate the "StatusCodeRuntimeDxe.debug" file in your Build
>>>> directory (ie. under the location listed in the error report). Then,
>>>> please disassemble it with "objdump -S". The fault location in the
>>>> disassembly can be found based on RIP, ImageBase and EntryPoint;
>>>
>>> I don't think the exact instruction at that address really matters. The
>>> main question appears to be why RIP and RSP both point into the
>>> same page (see also the subject of Anthony's mail).
>>
>> I'm not 100% what is going on,
> 
> me neither :)
> 
>> but if this (executable code on stack) is
>> happening in grub is there something which is explicitly forbidden to UEFI
>> apps by the UEFI spec?
> 
> Yes, there is. This small OvmfPkg patch only enables the edk2 feature
> added by Star Zeng in
> <https://github.com/tianocore/edk2/commit/5630cdfe> for OVMF. That patch
> (also referenced in my commit message by SVN rev) says,
> 
> This feature is added for UEFI spec that says
> "Stack may be marked as non-executable in identity mapped page
> tables".
> A PCD PcdSetNxForStack is added to turn on/off this feature, and it
> is FALSE by default.
> 
> A UEFI app runs (well, *starts*, anyway) before ExitBootServices() /
> SetVirtualAddressMap(), so it's bound by the above.
> 
> The spec passage above is quoted from "2.3.2 IA-32 Platforms", and
> "2.3.4 x64 Platforms", in chapter "2.3 Calling Conventions", where the
> boot services time environment is specified.
> 
> This is new in UEFI-2.5, and it comes from Mantis ticket 1224: "Adding
> support for No executable data areas".
> 
> ... The question could be then if grub (in Wheezy) should be adapted to
> UEFI-2.5 (if that's possible) or if OVMF should be built without this
&

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

[Laszlo Ersek]

On 09/11/15 16:10, Josh Triplett wrote:
> On Fri, Sep 11, 2015 at 01:43:53PM +0200, Laszlo Ersek wrote:
>> On 09/09/15 12:48, Laszlo Ersek wrote:
>>> On 09/09/15 11:37, Ian Campbell wrote:
>>>> On Wed, 2015-09-09 at 01:06 -0600, Jan Beulich wrote:
>>>>>>>> On 09.09.15 at 00:23, <ler...@redhat.com> wrote:
>>>>>> On 09/08/15 19:26, Anthony PERARD wrote:
>>>>>>> And I get this on the console:
>>>>>>> Welcome to GRUB!
>>>>>>>
>>>>>>>  X64 Exception Type - 0E(#PF - Page-Fault)  CPU Apic ID -
>>>>>>>  
>>>>>>> RIP  - 0F5F8918, CS  - 0028, RFLAGS -
>>>>>>> 00210206
>>>>>>> ExceptionData - 0011
>>>>>>> RAX  - , RCX - 07FCE000, RDX -
>>>>>>> 
>>>>>>> RBX  - 0B6092C0, RSP - 0F5F8590, RBP -
>>>>>>> 0B608EA0
>>>>>>> RSI  - 0F5F8838, RDI - 0B608EA0
>>>>>>> R8   - , R9  - 0B609200, R10 -
>>>>>>> 
>>>>>>> R11  - 000A, R12 - , R13 -
>>>>>>> 001B
>>>>>>> R14  - 0B609360, R15 - 
>>>>>>> DS   - 0008, ES  - 0008, FS  -
>>>>>>> 0008
>>>>>>> GS   - 0008, SS  - 0008
>>>>>>> CR0  - 8033, CR2 - 0F5F8918, CR3 -
>>>>>>> 0F597000
>>>>>>> CR4  - 0668, CR8 - 
>>>>>>> DR0  - , DR1 - , DR2 -
>>>>>>> 
>>>>>>> DR3  - , DR6 - 0FF0, DR7 -
>>>>>>> 0400
>>>>>>> GDTR - 0F57BF18 003F, LDTR - 
>>>>>>> IDTR - 0EEA5018 0FFF,   TR - 
>>>>>>> FXSAVE_STATE - 0F5F81F0
>>>>>>>  Find PE image 
>>>>>> /build/xen-unstable/src/xen-unstable/tools/firmware/ovmf-dir
>>>>>> -remote/Build
>>>>>> /OvmfX64/DEBUG_GCC49/X64/IntelFrameworkModulePkg/Universal/StatusCode/R
>>>>>> untime
>>>>>> Dxe/StatusCodeRuntimeDxe/DEBUG/StatusCodeRuntimeDxe.dll 
>>>>>> (ImageBase=0F556000, EntryPoint=0F55628F) 
>>>>>>>
>>>>>>> I did check with other guest (Windows, Ubuntu, Debian Jessie), and
>>>>>>> they are
>>>>>>> working correctly. Debian Wheezy is the only one that fail.
>>>>>>
>>>>>> I don't have an environment to reproduce this in. I think we should try
>>>>>> to understand this problem better, before deciding how to make it go
>>>>>> away.
>>>>>>
>>>>>> Please locate the "StatusCodeRuntimeDxe.debug" file in your Build
>>>>>> directory (ie. under the location listed in the error report). Then,
>>>>>> please disassemble it with "objdump -S". The fault location in the
>>>>>> disassembly can be found based on RIP, ImageBase and EntryPoint;
>>>>>
>>>>> I don't think the exact instruction at that address really matters. The
>>>>> main question appears to be why RIP and RSP both point into the
>>>>> same page (see also the subject of Anthony's mail).
>>>>
>>>> I'm not 100% what is going on,
>>>
>>> me neither :)
>>>
>>>> but if this (executable code on stack) is
>>>> happening in grub is there something which is explicitly forbidden to UEFI
>>>> apps by the UEFI spec?
>>>
>>> Yes, there is. This small OvmfPkg patch only enables the edk2 feature
>>> added by Star Zeng in
>>> <https://github.com/tianocore/edk2/commit/5630cdfe> for OVMF. That patch
>>> (also referenced in my commit message by SVN rev) says,
>>>
>>> This feature is added for UEFI spec that says
>>> "Stack may be marked as non-executable in identity mapped page
>>> tables".
>>> A PCD PcdSetNxForStack is added to 

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

[Laszlo Ersek]

On 09/10/15 05:05, Zeng, Star wrote:
> On 2015/9/9 18:48, Laszlo Ersek wrote:
>> me neither :)
>>
>>> but if this (executable code on stack) is
>>> happening in grub is there something which is explicitly forbidden to
>>> UEFI
>>> apps by the UEFI spec?
>>
>> Yes, there is. This small OvmfPkg patch only enables the edk2 feature
>> added by Star Zeng in
>> <https://github.com/tianocore/edk2/commit/5630cdfe> for OVMF. That patch
>> (also referenced in my commit message by SVN rev) says,
>>
>>  This feature is added for UEFI spec that says
>>  "Stack may be marked as non-executable in identity mapped page
>>  tables".
>>  A PCD PcdSetNxForStack is added to turn on/off this feature, and it
>>  is FALSE by default.
>>
>> A UEFI app runs (well, *starts*, anyway) before ExitBootServices() /
>> SetVirtualAddressMap(), so it's bound by the above.
>>
>> The spec passage above is quoted from "2.3.2 IA-32 Platforms", and
>> "2.3.4 x64 Platforms", in chapter "2.3 Calling Conventions", where the
>> boot services time environment is specified.
>>
>> This is new in UEFI-2.5, and it comes from Mantis ticket 1224: "Adding
>> support for No executable data areas".
>>
>> ... The question could be then if grub (in Wheezy) should be adapted to
>> UEFI-2.5 (if that's possible) or if OVMF should be built without this
>> feature.
>>
>> Hmmm. Actually, I'm torn about the default for PcdSetNxForStack.
>>
>> Namely, Mantis ticket 1224 has come up before. There's another edk2
>> sub-feature related to this UEFI spec feature / Mantis ticket; the
>> properties table (controlled by "PcdPropertiesTableEnable"), and the
>> effects it has on the UEFI memory map, and the requirements it presents
>> for UEFI OSes.
>>
>> *That* sub-feature is extremely intrusive.
>> "MdeModulePkg/MdeModulePkg.dec" sets "PcdPropertiesTableEnable" TRUE by
>> default, and OvmfPkg inherits it. I have not overridden that default
>> just yet in OvmfPkg because the properties table feature depends on
>> something *else* too: sections in runtime DXE driver binaries must be
>> aligned at 4KB, and that is not ensured for OvmfPkg (yet?). Therefore,
>> the properties table feature is not active in OVMF at the moment due to
>> a "random build tools circumstance" -- and not because the feature flag
>> is actually disabled.
>>
>> Now, the properties table feature absolutely cannot be (effectively)
>> enabled in OVMF as a default. It would break Windows 7 / Windows Server
>> 2008 R2. A huge number of users run such guests for GPU passthrough.
>>
>> The idea that just crossed my mind was to introduce a new build flag for
>> OVMF, like -D NOEXEC_DATA_ENABLE. And this would then control
>> PcdSetNxForStack *and* PcdPropertiesTableEnable *together*:
>>
>> if NOEXEC_DATA_ENABLE:
>>PcdSetNxForStack := TRUE
>>PcdPropertiesTableEnable := TRUE
>> else
>>PcdSetNxForStack := FALSE
>>PcdPropertiesTableEnable := FALSE
>>
>> However, I think that's a bad idea.
>>
>> "PcdPropertiesTableEnable" breaks a very widely used guest OS for which
>> there is no update in sight (ie. no Service Pack 2 for Windows 7 /
>> Windows Server 2008 R2), but is otherwise supposed to be supported for
>> years to come.
>>
>> Whereas Debian Wheezy is not as widely used as a guest (for one: it
>> "competes" with all the other Linux distros from the same timeframe).
>> Debian Wheezy also provides a quite non-intrusive upgrade path (to
>> Jessie), which is not the case for Windows 7. So the breakage casued by
>> setting PcdSetNxForStack has much smaller impact, I think, and the
>> benefits might outweigh the breakage.
>>
>> Which just means that a heavy-handed -D NOEXEC_DATA_ENABLE, like above,
>> would not be appropriate. PcdSetNxForStack set, and
>> PcdPropertiesTableEnable clear, is a valid configuration.
>>
>> In any case, I sort of convinced myself that Wheezy's grub is not at
>> fault; it was simply written against an earlier release of the UEFI spec.
>>
>> How about this:
>>
>> - (somewhat unrelatedly, but for completeness):
>>I post a patch that exposes PcdPropertiesTableEnable with a build
>>time flag (NX_PROP_TABLE_ENABLE) with an OVMF-default of FALSE,
>>
>> - I post another patch that exposes PcdSetNxForStack with a build time
>>flag (NX_STACK_ENABLE) with an OVMF-def

Re: [Xen-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

[Laszlo Ersek]

On 09/10/15 08:19, Alexander Graf wrote:
> 
> 
>> Am 10.09.2015 um 07:32 schrieb Jordan Justen :

>> Laszlo's email raised the GPL question, but I was not sure what the
>> EDK II community would accept with regards to GPL. Thus ... I asked. I
>> guess I'm getting a better idea with regards to Apple and HP. :)
>>
>> In your opinion, would we be able to discuss patches for a *separate*
>> repo with GplDriverPkg on edk2-devel?
> 
> In fact, could we just make the non-free FAT source and GPL FAT
> source both be git submodules?

We've discussed submodules in the past (for other purposes). The
consensus seemed to be that most people dislike them (me included).

UEFI drivers are supposed to be modular / well separable (for one, they
can be shipped by third parties in binary-only form; which was a design
goal of UEFI). And specifically in the FAT driver's case, the source
doesn't even live inside the main repo at the moment, so turning it into
a source submodule might not be a step back.

But... I just don't like it. We should be moving towards a grand unified
repo, where cross-module changes and dependencies are possible to
implement with carefully segmented patch sets. The FAT driver's source
lives outside for non-technical reasons. Rather than codifying that
situation forever with a git submodule, I'd prefer some solution that
leaves us with a standalone repo.

I think I'm fuzzy on the details of the earlier git-submodule
discussion. In any case here's the link (I hope this is the right one):

http://thread.gmane.org/gmane.comp.bios.tianocore.devel/15168

> Then whoever clones the repo can get
> the license flavor he's least scared about.

I think for many companies it is important that a developer of theirs
who is "blissfully ignorant" of licensing questions simply *cannot* make
a mistake (eg. by copying code from the "wrong" directory, or by using
the "wrong" submodule). It should be foolproof.

> Or alternatively instead
> of pulling in a GPL licensed FAT driver we use a BSD licensed one.
> I'm sure someone has one of those too ;).

I'm not sure at all. Do you have a pointer? :)

> Also for the record, the FAT driver problem is that the source
> license states that it can not be used in certain circumstances,
> which by common interpretation makes it non-free.

I agree. The restriction on use conflicts both the FSF's defintion of
Free Software, and the OSI's definition of Open Source Software.

> The fact that there
> is a binary or source doesn't matter fwiw.

Right.

Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] OVMF BoF @ KVM Forum 2015

[Laszlo Ersek]

On 08/10/15 18:24, Laszlo Ersek wrote:
> Hi.
> 
> Let's do an OVMF BoF at this year's KVM Forum too.

Here's a preliminary task list, after some off-list discussion (I tried
to incorporate comments):

- create GPL'd fork called "ovmf" for expediting virt development
  (OvmfPkg, ArmVirtPkg)
  - maybe leverage the feature under
<http://permalink.gmane.org/gmane.comp.bios.edk2.devel/941> for
setting up a separate "tianocore/edk2-gpl" repo, for GPL'd
contributions [Jordan]
- repo separation by license could make things harder for packagers
  and QEMU bundling [Laszlo]
- document the rules / justification for "ovmf" (licensing
  conflicts, non-technical blockage on edk2 etc).
- No new mailing list needed
- push RH's downstream-only patches to "ovmf", wherever that makes
  sense
- remove encumbered FAT driver
- import Peter Batard's GPL r/o FAT driver port of GRUB's
- secure OpenSSL linking exception for the former from the copyright
  holders (Peter Batard, GRUB project)
- "ovmf" should be periodically rebased / should fetch+merge edk2 as
  master (arguments both for and against merging); distros should
  then track "ovmf" as their upstream, not edk2
- get OVMF into Fedora (as pkg) and QEMU (as bundled binary)
- do OVMF releases, maybe in sync with QEMU's releases
  - we can probably build from known good revisions from git [Alex]
- revive Q35 SATA driver work / poke Reza
  - Hannes and Gabriel have refreshed patches, but their versions differ


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

[Laszlo Ersek]

On 09/09/15 11:37, Ian Campbell wrote:
> On Wed, 2015-09-09 at 01:06 -0600, Jan Beulich wrote:
> On 09.09.15 at 00:23,  wrote:
>>> On 09/08/15 19:26, Anthony PERARD wrote:
 And I get this on the console:
 Welcome to GRUB!

  X64 Exception Type - 0E(#PF - Page-Fault)  CPU Apic ID -
  
 RIP  - 0F5F8918, CS  - 0028, RFLAGS -
 00210206
 ExceptionData - 0011
 RAX  - , RCX - 07FCE000, RDX -
 
 RBX  - 0B6092C0, RSP - 0F5F8590, RBP -
 0B608EA0
 RSI  - 0F5F8838, RDI - 0B608EA0
 R8   - , R9  - 0B609200, R10 -
 
 R11  - 000A, R12 - , R13 -
 001B
 R14  - 0B609360, R15 - 
 DS   - 0008, ES  - 0008, FS  -
 0008
 GS   - 0008, SS  - 0008
 CR0  - 8033, CR2 - 0F5F8918, CR3 -
 0F597000
 CR4  - 0668, CR8 - 
 DR0  - , DR1 - , DR2 -
 
 DR3  - , DR6 - 0FF0, DR7 -
 0400
 GDTR - 0F57BF18 003F, LDTR - 
 IDTR - 0EEA5018 0FFF,   TR - 
 FXSAVE_STATE - 0F5F81F0
  Find PE image 
>>> /build/xen-unstable/src/xen-unstable/tools/firmware/ovmf-dir
>>> -remote/Build
>>> /OvmfX64/DEBUG_GCC49/X64/IntelFrameworkModulePkg/Universal/StatusCode/R
>>> untime
>>> Dxe/StatusCodeRuntimeDxe/DEBUG/StatusCodeRuntimeDxe.dll 
>>> (ImageBase=0F556000, EntryPoint=0F55628F) 

 I did check with other guest (Windows, Ubuntu, Debian Jessie), and
 they are
 working correctly. Debian Wheezy is the only one that fail.
>>>
>>> I don't have an environment to reproduce this in. I think we should try
>>> to understand this problem better, before deciding how to make it go
>>> away.
>>>
>>> Please locate the "StatusCodeRuntimeDxe.debug" file in your Build
>>> directory (ie. under the location listed in the error report). Then,
>>> please disassemble it with "objdump -S". The fault location in the
>>> disassembly can be found based on RIP, ImageBase and EntryPoint;
>>
>> I don't think the exact instruction at that address really matters. The
>> main question appears to be why RIP and RSP both point into the
>> same page (see also the subject of Anthony's mail).
> 
> I'm not 100% what is going on,

me neither :)

> but if this (executable code on stack) is
> happening in grub is there something which is explicitly forbidden to UEFI
> apps by the UEFI spec?

Yes, there is. This small OvmfPkg patch only enables the edk2 feature
added by Star Zeng in
 for OVMF. That patch
(also referenced in my commit message by SVN rev) says,

This feature is added for UEFI spec that says
"Stack may be marked as non-executable in identity mapped page
tables".
A PCD PcdSetNxForStack is added to turn on/off this feature, and it
is FALSE by default.

A UEFI app runs (well, *starts*, anyway) before ExitBootServices() /
SetVirtualAddressMap(), so it's bound by the above.

The spec passage above is quoted from "2.3.2 IA-32 Platforms", and
"2.3.4 x64 Platforms", in chapter "2.3 Calling Conventions", where the
boot services time environment is specified.

This is new in UEFI-2.5, and it comes from Mantis ticket 1224: "Adding
support for No executable data areas".

... The question could be then if grub (in Wheezy) should be adapted to
UEFI-2.5 (if that's possible) or if OVMF should be built without this
feature.

Hmmm. Actually, I'm torn about the default for PcdSetNxForStack.

Namely, Mantis ticket 1224 has come up before. There's another edk2
sub-feature related to this UEFI spec feature / Mantis ticket; the
properties table (controlled by "PcdPropertiesTableEnable"), and the
effects it has on the UEFI memory map, and the requirements it presents
for UEFI OSes.

*That* sub-feature is extremely intrusive.
"MdeModulePkg/MdeModulePkg.dec" sets "PcdPropertiesTableEnable" TRUE by
default, and OvmfPkg inherits it. I have not overridden that default
just yet in OvmfPkg because the properties table feature depends on
something *else* too: sections in runtime DXE driver binaries must be
aligned at 4KB, and that is not ensured for OvmfPkg (yet?). Therefore,
the properties table feature is not active in OVMF at the moment due to
a "random build tools circumstance" -- and not because the feature flag
is actually disabled.

Now, the properties table feature absolutely cannot be (effectively)
enabled in OVMF as a default. It would break Windows 7 / Windows Server
2008 R2. A huge number of users run such guests for GPU passthrough.

The idea 

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

[Laszlo Ersek]

On 09/09/15 13:07, Ian Campbell wrote:
> On Wed, 2015-09-09 at 12:48 +0200, Laszlo Ersek wrote:
> 
> Thanks for all the info, I think I get it (although its not clear to me
> whether how an app can claim to be UEFI 2.5 capable and what the transition
> plan for legacy applications was going to be).
> 
>> ... The question could be then if grub (in Wheezy) should be adapted to
>> UEFI-2.5 (if that's possible)
> 
> I don't know either I'm afraid.
> 
> [...]
>> Hmmm. Actually, I'm torn about the default for PcdSetNxForStack.
> 
> I have a question: What attack vector is setting the stack as Nx in OVMF
> (or even UEFI generally) trying to protect against? Or is this being done
> for a reason other than security?

I think it is being done for security, generally speaking (ie. as far as
edk2 and the UEFI spec are concerned).

Specifically for OVMF, I wrote the patch because Paolo suggested it,
after (I think) he saw Star's feature patch on the edk2 mailing list. I
thought it was a good suggestion, even in case we had no particular
attack in mind: OVMF is frequently used as a UEFI development / test
bed, and we try to enable new edk2 / UEFI features in it, unless the
firmware size increase would be large, or something would break. (In
which cases we usually bracket the new feature with build time flags.)

I did consider regressions while writing this patch. In the commit
message I mentioned "-cpu ,-nx" as a way to turn of NX support in
the virtual CPU (which the edk2 feature dynamically detects and depends
on), should anything break. I did not expect two things: (a) old grub
actually executes stuff from the stack, (b) Xen has no way (?) to
disable NX in a VCPU (or maybe that would be detrimental for other reasons).

> I understand why it is done for kernels and apps, but where does the
> untrusted element which is being protected against come from when running
> UEFI?

I'm sure this is explained in the five ECR documents attached to Mantis
ticket 1224:

https://mantis.uefi.org/mantis/view.php?id=1224

Unfortunately, I don't think I can just publish those ECRs here (or dump
the mantis ticket).

I have no clue why UEFI development is so secretive. I had been annoyed
by not seeing mantis tickets myself (and thereby missing the
justification behind new UEFI features), so at some point I applied for
"non-voter, observer-only" membership in both the PIWG and the USWG, and
I got them. (I'm fuzzy on the details if this was helped by my being
@redhat.com -- it probably was.)

Perhaps you can also apply for membership (and read the ECRs on the
ticket), or hopefully Star (who implemented the feature) could summarize
the purpose here?

(I won't try, based on the ECRs, because that will unavoidably put me in
the position where I have to explain and defend the feature. Thanks, but
no, thanks :))

Cheers
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

[Laszlo Ersek]

On 09/09/15 13:30, Paolo Bonzini wrote:
> 
> 
> On 09/09/2015 13:07, Ian Campbell wrote:
>> I have a question: What attack vector is setting the stack as Nx in OVMF
>> (or even UEFI generally) trying to protect against? Or is this being done
>> for a reason other than security?
>>
>> I understand why it is done for kernels and apps, but where does the
>> untrusted element which is being protected against come from when running
>> UEFI?
> 
> I guess something could attack shim.efi or GRUB, and subvert secure
> boot's chain of trust.

... or the firmware could be fed some malicious data over the network,
when the fw (e.g. shim) boots off PXE (or, in case of edk2, HTTP), and a
buffer overflow could lead to the execution of arbitrary code?...



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

[Laszlo Ersek]

On 09/09/15 09:06, Jan Beulich wrote:
 On 09.09.15 at 00:23,  wrote:
>> On 09/08/15 19:26, Anthony PERARD wrote:
>>> And I get this on the console:
>>> Welcome to GRUB!
>>>
>>>  X64 Exception Type - 0E(#PF - Page-Fault)  CPU Apic ID -  
>>> RIP  - 0F5F8918, CS  - 0028, RFLAGS - 00210206
>>> ExceptionData - 0011
>>> RAX  - , RCX - 07FCE000, RDX - 
>>> RBX  - 0B6092C0, RSP - 0F5F8590, RBP - 0B608EA0
>>> RSI  - 0F5F8838, RDI - 0B608EA0
>>> R8   - , R9  - 0B609200, R10 - 
>>> R11  - 000A, R12 - , R13 - 001B
>>> R14  - 0B609360, R15 - 
>>> DS   - 0008, ES  - 0008, FS  - 0008
>>> GS   - 0008, SS  - 0008
>>> CR0  - 8033, CR2 - 0F5F8918, CR3 - 0F597000
>>> CR4  - 0668, CR8 - 
>>> DR0  - , DR1 - , DR2 - 
>>> DR3  - , DR6 - 0FF0, DR7 - 0400
>>> GDTR - 0F57BF18 003F, LDTR - 
>>> IDTR - 0EEA5018 0FFF,   TR - 
>>> FXSAVE_STATE - 0F5F81F0
>>>  Find PE image 
>> /build/xen-unstable/src/xen-unstable/tools/firmware/ovmf-dir-remote/Build
>> /OvmfX64/DEBUG_GCC49/X64/IntelFrameworkModulePkg/Universal/StatusCode/Runtime
>> Dxe/StatusCodeRuntimeDxe/DEBUG/StatusCodeRuntimeDxe.dll 
>> (ImageBase=0F556000, EntryPoint=0F55628F) 
>>>
>>> I did check with other guest (Windows, Ubuntu, Debian Jessie), and they are
>>> working correctly. Debian Wheezy is the only one that fail.
>>
>> I don't have an environment to reproduce this in. I think we should try
>> to understand this problem better, before deciding how to make it go away.
>>
>> Please locate the "StatusCodeRuntimeDxe.debug" file in your Build
>> directory (ie. under the location listed in the error report). Then,
>> please disassemble it with "objdump -S". The fault location in the
>> disassembly can be found based on RIP, ImageBase and EntryPoint;
> 
> I don't think the exact instruction at that address really matters. The
> main question appears to be why RIP and RSP both point into the
> same page (see also the subject of Anthony's mail). I.e. we need to
> spot the entity setting the stack to a page that also contains code,
> or placing code on the stack.

Good point!

(... FWIW, I've had luck on several occasions in the past deducing the
the origin of the data from the data itself. So if we can see the "code
on the stack", maybe that could help us figure out where it comes from.
Just an idea; might not apply very well here.)

> That's unlikely to be found by identifying
> the instruction RIP points to, but rather (sadly not part of the state
> dump) something higher up the call chain.

As far as I can see, Debian switched from grub2 v1.99 to v2.02, from
Wheezy to Jessie. Based on the grub2 commit history, quite a few things
happened in grub2 in that timeframe. Should we perhaps ask the grub2
developers?

Thanks
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

[Laszlo Ersek]

On 09/09/15 14:08, Jan Beulich wrote:
 On 09.09.15 at 12:48,  wrote:
>> Personally I think that this dynamic approach is overkill (mainly
>> because I'm fine with being unable to install Debian Wheezy guests, both
>> wearing and not wearing my red fedora; and because the properties table
>> feature is not active for *any* OVMF guests anyway, in practice).
> 
> I can only guess that PCD stands for "Platform Configuration Data".

Yes, PCD stands for Platform Configuration Database.

> However, I would want to suggest an even more dynamic approach:
> Assuming that within the core UEFI code it ought to be possible to
> flip between executable and non-executable mapping of the stack,
> and considering that PE headers can carry target version numbers,
> how about reverting to an executable stack as long as there's at
> least one binary loaded that isn't claiming to be 2.5 compatible?

This would require very intrusive changes (to be implemented by people
other than me). Other concerns I have:

- I'm not sure if UEFI applications have any means to advertize what
  revision of the specification they target. (As you mention.)

- I could be mistaken, but this looks like it could weaken the
  protection offered by the platform feature. UEFI applications and
  UEFI drivers are expected to come from third parties. It could be
  argued that a non-compatible UEFI app or driver (like Wheezy's grub
  in this case) *should* preferably crash, immediately, in a controlled
  manner, instead of silently downgrading the protection for the stack,
  and thereby opening up an avenue for attacks.

  I'm not fully convinced about this, but it appears this should be
  controlled somewhere in the platform code. (Like a knob in the BIOS
  setup on physical platforms, or some enlighted info channel in
  guests.) Assuming we'd like it dynamic.

Thanks
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] EDK II & GPL - Re: [edk2] OVMF BoF @ KVM Forum 2015

[Laszlo Ersek]

On 09/09/15 18:17, Jordan Justen wrote:
> On 2015-09-09 01:57:51, Laszlo Ersek wrote:
>> On 08/10/15 18:24, Laszlo Ersek wrote:
>>> Hi.
>>>
>>> Let's do an OVMF BoF at this year's KVM Forum too.
>>
>> Here's a preliminary task list, after some off-list discussion (I tried
>> to incorporate comments):
>>
>> - create GPL'd fork called "ovmf" for expediting virt development
>>   (OvmfPkg, ArmVirtPkg)
>>   - maybe leverage the feature under
>> <http://permalink.gmane.org/gmane.comp.bios.edk2.devel/941> for
>> setting up a separate "tianocore/edk2-gpl" repo, for GPL'd
>> contributions [Jordan]
>> - repo separation by license could make things harder for packagers
>>   and QEMU bundling [Laszlo]
> 
> I would like OVMF to follow a plan for GPL that the whole EDK II
> community decides on.
> 
> I would also like to see EDK II add a (permissively licensed; BSD,
> MIT, etc) DriverPkg (DriversPkg?). We discussed this on the list
> recently:
> 
> http://thread.gmane.org/gmane.comp.bios.tianocore.devel/17544/focus=676
> 
> So, related to this, I wonder how the community would feel about a
> GplDriverPkg. Would the community allow it as a new package in EDK II
> directly, or would a separate repo be required?
> 
> With regards to adding it directly into the EDK II tree, here are some
> potential concerns that I might anticipate hearing from the community:
> 
> * It will make it easier for contributors to choose GPL compared to a
>   permissive license, thereby limiting some users of the contribution
> 
> * GPL code will more easily be copied into the permissively licensed
>   packages
> 
> * Some might refuse to look at EDK II entirely if it has a directory
>   with GPL source code in it
> 
> Of these, I personally only sympathize with the first.
> 
> Regarding the separate OVMF repo, my hope is that it is more of a OVMF
> specific working area, rather than a 'GPL OVMF'. For example, patches
> or features that we've not yet figured out how to upstream, but we
> hopefully plan to.

Yes, the "OVMF specific working area" is also my main goal with this.

If we can find a way to (a) replace the FAT driver with the libre
software one, and (b) more generally, accept GPL drivers, without
depending on this separate OVMF repo, that's great. So "owning" those
modules is not a goal per se, just something the new repo should cover
in case we can't solve it within edk2. (E.g. with your GplDriverPkg idea.)

> Additionally, it makes sense to use it as needed for OVMF specific
> releases. (Ie, OVMF release tags)

Good idea.

Thanks!
Laszlo

> 
> -Jordan
> 
>> - document the rules / justification for "ovmf" (licensing
>>   conflicts, non-technical blockage on edk2 etc).
>> - No new mailing list needed
>> - push RH's downstream-only patches to "ovmf", wherever that makes
>>   sense
>> - remove encumbered FAT driver
>> - import Peter Batard's GPL r/o FAT driver port of GRUB's
>> - secure OpenSSL linking exception for the former from the copyright
>>   holders (Peter Batard, GRUB project)
>> - "ovmf" should be periodically rebased / should fetch+merge edk2 as
>>   master (arguments both for and against merging); distros should
>>   then track "ovmf" as their upstream, not edk2
>> - get OVMF into Fedora (as pkg) and QEMU (as bundled binary)
>> - do OVMF releases, maybe in sync with QEMU's releases
>>   - we can probably build from known good revisions from git [Alex]
>> - revive Q35 SATA driver work / poke Reza
>>   - Hannes and Gabriel have refreshed patches, but their versions differ
>>
>> ___
>> edk2-devel mailing list
>> edk2-de...@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] OVMF BoF @ KVM Forum 2015

[Laszlo Ersek]

On 09/09/15 18:34, Ian Campbell wrote:
> On Wed, 2015-09-09 at 10:57 +0200, Laszlo Ersek wrote:
>> On 08/10/15 18:24, Laszlo Ersek wrote:
>>> Hi.
>>>
>>> Let's do an OVMF BoF at this year's KVM Forum too.
>>
>> Here's a preliminary task list
> 
> Thanks for including xen-devel in this. Was anyone from the Xen community
> present at the BoF (so far as you know)? Are there any minutes or anything
> like that for those interested in the discussion and reasoning rather than
> just the resulting action items?

Okay, second attempt at an answer. I *have* forgotten a great deal of
the sentences that were uttered at the BoF, but I mostly remember why we
wanted these things. :)

So let me see if I can elaborate on these (after all you are interested
in the reasoning in general, not just the discussions that I fail to
recall in detail):

>> , after some off-list discussion (I tried
>> to incorporate comments):
>>
>> - create GPL'd fork called "ovmf" for expediting virt development
>>   (OvmfPkg, ArmVirtPkg)
>>   - maybe leverage the feature under
>> <http://permalink.gmane.org/gmane.comp.bios.edk2.devel/941> for
>> setting up a separate "tianocore/edk2-gpl" repo, for GPL'd
>> contributions [Jordan]
>> - repo separation by license could make things harder for packagers
>>   and QEMU bundling [Laszlo]

So in this item (which, in the above form, is already obsolete) I
managed to mix up three separate things. (But Jordan then went on and
clarified those today.)

(1) One thing is a virt-oriented fork of edk2, without explicit
licensing-oriented goals. The main purpose of this fork would be to
expedite virt development (OvmfPkg, ArmVirtPkg, and central packages on
which the former two depend).

It has sometimes occurred that an OVMF feature got tied up in
inter-maintainer disagreement, or other non-technical reasons (lack of
review capacity etc). This holds back virt development, plus it has the
potential to force downstreams (let's be concrete: Red Hat at minimum)
to carry some patches in downstream only.

The fork would accelerate things here. We'd have a set of rules for
committing to the fork (and the divergence would have to be rebased
periodically, or alternatively edk2 patches would have to be merged into
the fork, periodically).

Considering this purpose (ie. expediting virt development) in isolation,
the fork should stick with the original edk2 licenses.

(2) The *ability* to provide the end user with free software (in the
FSF's definition) or open source software (in the OSI's definition),
which the current FAT driver is regrettably none of, is extremely important.

Currently the only alternative that appears feasible is Peter Batard's
UEFI port of GRUB's read-only FAT driver. That driver comes under the
GPL, and therefore it ties into topic (3) below.

However, note that if the in-tree FAT driver were liberated (= made Free
or Open Source Software, for example by dropping the "Additional Terms"
from its license, thereby rendering it 3-BSDL), then goal (2) would be
immediately achieved, and it wouldn't tie into goal (3) below.

(3) Accommodating drivers that contributors can (or are willing to)
submit only under the GPL would be nice. For example there has been such
a contribution from Ludovic Rousseau, a smart card reader protocol
implementation (a port from Linux).

Jordan's most recent suggestion was to actually keep GPL'd drivers
within edk2, under "GplDriverPkg". This is being discussed on
edk2-devel, so I'll move on.

>> - document the rules / justification for "ovmf" (licensing
>>   conflicts, non-technical blockage on edk2 etc).
>> - No new mailing list needed

Okay, so the rules. They would go like (obviously they are up for
discussion):

- submit your stuff to edk2-devel as always

- work with the reviewers / maintainers

- if you get demonstrably stuck, due to inter-maintainer deadlock (ie.
  you'd be fine implementing either maintainer's request, but their
  requirements *together* are unsatisfiable, because they conflict),
  the patches can be committed to the fork, subject to review *for* the
  fork

- same if there's just no feedback for a patchset

- same if the patches are blocked due to non-technical criticism

- maybe the same if the technical feedback would require
  *disproportionate* effort (ie. cross-package refactorings), esp.
  involving client (=platform) packages that are not related to virt.
  We have to be careful with this one (it's not a blanket excuse, and
  arguments are bound to be somewhat subjective here), but such
  unjustified / overarching / disproportionate requirements can block
  the upstreaming of a feature (developed under a deadline) for good.

  Example: consider a refactoring that straddles DuetPkg or EmulatorPkg
  *and* MdeModulePkg, 

Re: [Xen-devel] OVMF BoF @ KVM Forum 2015

[Laszlo Ersek]

On 09/09/15 18:34, Ian Campbell wrote:
> On Wed, 2015-09-09 at 10:57 +0200, Laszlo Ersek wrote:
>> On 08/10/15 18:24, Laszlo Ersek wrote:
>>> Hi.
>>>
>>> Let's do an OVMF BoF at this year's KVM Forum too.
>>
>> Here's a preliminary task list
> 
> Thanks for including xen-devel in this. Was anyone from the Xen community
> present at the BoF (so far as you know)?

Noone was. And I know it for a fact, because all of the handful of BoF
participants were sitting around one table. :)

(If someone speaks up now, "hey I was there, and I'm a Xen guy", then
I'll just dig myself a pit.)

> Are there any minutes or anything
> like that for those interested in the discussion and reasoning rather than
> just the resulting action items?

Not really; I think this todo list is pretty comprehensive. I remember
talking a lot and having trouble breathing (I had gotten sick just a few
days earlier -- yay crowded conferences and parties), but I tend to
speak in many details about few things, and not concisely about many things.

Should you care about those details, I've now forgotten them all. They
probably weren't important anyway. I recall trying to convince Jordan
politely to review my SMM patches. We probably discussed some SMM details.

... Please ask Jordan or the other participants, they weren't sick, and
they don't have a chronic verbosity problem.

... Man, it must be great to work with me! ;)

Thanks for your interest!
Laszlo

> 
> Thanks,
> Ian.
> 
>> , after some off-list discussion (I tried
>> to incorporate comments):
>>
>> - create GPL'd fork called "ovmf" for expediting virt development
>>   (OvmfPkg, ArmVirtPkg)
>>   - maybe leverage the feature under
>> <http://permalink.gmane.org/gmane.comp.bios.edk2.devel/941> for
>> setting up a separate "tianocore/edk2-gpl" repo, for GPL'd
>> contributions [Jordan]
>> - repo separation by license could make things harder for packagers
>>   and QEMU bundling [Laszlo]
>> - document the rules / justification for "ovmf" (licensing
>>   conflicts, non-technical blockage on edk2 etc).
>> - No new mailing list needed
>> - push RH's downstream-only patches to "ovmf", wherever that makes
>>   sense
>> - remove encumbered FAT driver
>> - import Peter Batard's GPL r/o FAT driver port of GRUB's
>> - secure OpenSSL linking exception for the former from the copyright
>>   holders (Peter Batard, GRUB project)
>> - "ovmf" should be periodically rebased / should fetch+merge edk2 as
>>   master (arguments both for and against merging); distros should
>>   then track "ovmf" as their upstream, not edk2
>> - get OVMF into Fedora (as pkg) and QEMU (as bundled binary)
>> - do OVMF releases, maybe in sync with QEMU's releases
>>   - we can probably build from known good revisions from git [Alex]
>> - revive Q35 SATA driver work / poke Reza
>>   - Hannes and Gabriel have refreshed patches, but their versions differ
>>
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] OVMF BoF @ KVM Forum 2015

[Laszlo Ersek]

Hi.

Let's do an OVMF BoF at this year's KVM Forum too.

Paolo will present

  Securing secure boot: system management mode in KVM and Tiano Core

on Thursday, August 20, in the 5:00pm - 5:30pm time slot.

Right after that, the BoF section starts at 5:30pm:

  http://events.linuxfoundation.org/events/kvm-forum/program/schedule

We should convene and discuss stuff. I don't have an agenda, so people
should bring their ideas and questions (famous last words).

As food for thought, I tried to collect the feature-looking patches from
the git history that have been committed since last year's KVM Forum,
and to match them against patch sets on the mailing list:

  git log --reverse --oneline --since=2014-10-14 -- \
  OvmfPkg/ \
  ArmVirtPkg/ \
  ArmPlatformPkg/ArmVirtualizationPkg/

I attempted to sort them into categories. You can see the list below.
The ordering is totally random, it's just what I ended up with.
Corrections / additions welcome.

Personally, one (missing) feature I'd like to see discussed is
SataControllerDxe in OVMF. SMM will require Q35, and the only IDE
that Q35 speaks is SATA / AHCI. (And you can't disable that controller
on Q35.)

Anyway, here goes.

Features completed
--

(... unless marked [pending])

- Xen guest:

  - PV block driver:
[PATCH v4 00/19] Introducing Xen PV block driver to OVMF

  - Xen for ARM:
[PATCH v5 00/29] Xen/ARM guest support

- PCI / hw related:

  - PCI on ARM; detect VGA and USB keyboard:
[PATCH v3 00/28] ArmVirtualizationPkg/ArmVirtualizationQemu: enable PCI
[PATCH 0/4] ArmVirtualizationPkg: PlatformIntelBdsLib: dynamic console setup

  - support for Q35:
[PATCH v6 0/9] OVMF: Add support for Qemu Q35 machine type
[PATCH 1/1] OvmfPkg: QemuBootOrderLib: parse OFW device path nodes of PCI 
bridges

  - USB3 (ARM and x86):
[PATCH v2 2/4] ArmVirtualizationPkg/ArmVirtualizationQemu: include XHCI 
driver
[PATCH v2 4/4] OvmfPkg: include XHCI driver

  - support TCO watchdog emulation features:
[PATCH v5 2/2] OvmfPkg/PlatformPei: Initialise RCBA (B0:D31:F0 0xf0) 
register

  - virtio-vga:
[PATCH] Add virtio-vga support

  - support extra PCI root buses for NUMA-locality with assigned
devices:
[PATCH v3 00/23] OvmfPkg: support extra PCI root buses

- QEMU config integration:

  - fw_cfg, boot order, and -kernel booting on ARM:
[PATCH v4 00/13] ArmVirtualizationQemu: support fw_cfg, bootorder, '-kernel'
[PATCH 0/3] ArmVirtPkg: drop support for the ARM BDS

  - support for -boot menu=on[,splash-time=N]:
[PATCH v2 0/3] OVMF, ArmVirt: consume QEMU's -boot menu=on[,splash-time=N]

  - ACPI tables for ARM:
[PATCH v2 0/3] ACPI over fw_cfg for ARM/AARCH64 qemu guests

  - SMBIOS features: Type 0 default, and SMBIOS 3.0 support on ARM and
x86:
[PATCH] OvmfPkg/SMBIOS: Provide default Type 0 (BIOS Information) structure
[PATCH v2 0/6] ArmVirtPkg/ArmVirtQemu: support SMBIOS
[PATCH 0/9] OvmfPkg, ArmVirtPkg: SMBIOS 3.0, round 2

- ARM specific:

  - fun with the caches:
[PATCH v4 0/5] ArmVirtualizationPkg: explicit cache maintenance

  - secure boot:
[PATCH v3 0/3] ArmVirtualizationQemu: enable support for UEFI Secure Boot

  - performance optimization:
[PATCH v2 0/6] ArmPkg/ArmVirtPkg: GIC revision detection

  - better handling for the typical Linux terminal (generic driver code,
hooked up to ArmVirt):
[PATCH V4 0/5] Add TtyTerm terminal type

- SMM for OVMF (in progress):
[PATCH 00/11] Bits and pieces
[PATCH 00/58] OvmfPkg: support SMM for better security (single VCPU, IA32) 
[pending]

- Build system:

  - moving to NASM:
[PATCH 0/7] Convert OVMF assembly to NASM
[PATCH v2 0/6] OvmfPkg/XenBusDxe: Convert *.asm to NASM.

  - accept UTF-8 in .uni files:
[PATCH v4 00/10] Support UTF-8 in .uni string files

  - LLVM/clang support for AARCH64 (in progress):
[PATCH v4 00/13] BaseTools: unify all GCC linker scripts
[PATCH v4 0/7] small model and clang support for AARCH64 [pending]

- UEFI compliance:

  - support for OsIndications:
[PATCH v2 0/9] OvmfPkg: PlatformBdsLib cleanups and improvements

  - signal ReadyToBoot:
[PATCH 1/8] OvmfPkg/PlatformBdsLib: Signal ReadyToBoot before booting QEMU 
kernel

  - signal EndOfDxe:
[PATCH v2] ArmVirtPkg: signal EndOxDxe event in PlatformBsdInit
[PATCH v2 0/6] OvmfPkg: save S3 state at EndOfDxe

  - fix Serial IO Protocol issues flagged by SCT
[PATCH V4 0/5] Some improvements on serial terminal

- other

  - big OVMF guests:
[PATCH v2 0/4] OvmfPkg: enable = 64 GB guests

  - IPv6 (conditionally enabled):
[PATCH v2] OvmfPkg: enable the IPv6 support

  - many fixes for toolchain warnings and C language misuse

Thanks
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] The size of memory is wrong inside of virtual machine(VM) when using OVMF

[Laszlo Ersek]

On 06/07/15 14:29, Wei Liu wrote:
 On Mon, Jun 01, 2015 at 09:13:08AM +, Maoming wrote:
 Hi all:
I encountered a troublesome problem about OVMF.
I used OVMF.fd as a BIOS of virtual machine(VM).

1、my environment:
xen_version: 4.6-unstable
I git clone xen from git://xenbits.xen.org/xen.git. configure it and 
 parameters as below:
./configure --prefix=/usr/ --libdir=/usr/lib/  --enable-ovmf then 
 make  make install, after that I reboot my host OS(suse11sp3).

 There is a same problem in KVM too.

2、problem:
I started a VM whose memory is 64G in the host.
The size of memory inside of the VM is wrong while it is OK when I 
 check it in the host using xl list.
But, when I changed the memory to 63G,it was both OK.
(1)64G memory
inside of VM using free to check:
 total   used   free sharedbuffers 
 cached
Mem:   3715640 4959163219724  0  22060 
 175136
-/+ buffers/cache: 2987203416920
Swap:  4046840  04046840
It is only 3.5G.

in the host using xl list to check:
NameID   Mem VCPUs  State 
   Time(s)
Domain-0 0  305516 r- 
 861.2
redhat   4 65536 2 r- 
   5.9

(2)63G memory
inside of VM using free to check:
 total   used   free sharedbuffers 
 cached
Mem:  649182241083912   63834312  0  22188 
 175344
-/+ buffers/cache: 886380   64031844
Swap:  4046840  04046840
It is OK.

in the host using xl list to check:
NameID   Mem VCPUs  State 
   Time(s)
Domain-0 0  305516 r- 
 821.2
redhat   3 64512 2 -b 
  48.5

3、my cfg file:
builder = hvm
name = redhat
memory = 65536
maxmem = 65536
vcpus = 2
bios = ovmf
boot = dc
sdl=0
disk = [ 'file:/test/image/redhat6_3.img,xvda,w' ]
vnc = 1
vnclisten = '9.61.1.31'
vncdisplay = 0

Any thought on this?
Any help will be appreciated.
If you need some other information, please let me know. :)

 
 It looks like there is some kind of truncation inside OVMF. But I don't
 have a test box that has so much memory so I cannot try it myself.

The issue is real. I've been working on some patches today for this.
I'll soon send an RFC series.

It's actually easy to *test* this scenario: just create a 128GB or so
file, with fallocate, on a sufficiently big filesystem. Then format it
with mkswap and add it with swapon. I have strict memory overcommit
settings on my laptop (/proc/sys/vm/overcommit_memory = 2), but with
such a swap file, a = 64GB guest can easily be started.

(I used my old spindle disk for the swap file. Since the guest is doing
practically nothing, it doesn't cause the disk to thrash.)

Thanks
Laszlo

 Since it manifests on both Xen and KVM I don't really have an idea about
 what's going on.
 
 The only thing I can say is that the tested OVMF tree for Xen is 
 
 http://xenbits.xen.org/gitweb/?p=osstest/ovmf.git;a=summary
 xen-tested-master
 
 The one in xen.git is updated periodically. Make sure you use our
 latest tested branch so you can get fixes from upstream.
 
 Wei.
 
Thanks!
  -mao
 
 ___
 Xen-devel mailing list
 Xen-devel@lists.xen.org
 http://lists.xen.org/xen-devel
 
 
 --
 ___
 edk2-devel mailing list
 edk2-de...@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/edk2-devel
 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] A problem about the memory size of virtual machine(VM) when using OVMF

[Laszlo Ersek]

I have the impression that this is HTML mail. Please don't post HTML
mail; it falls apart when it is quoted.

That said,

On 06/04/15 16:07, Maoming wrote:
 Hi all：
 
I started a virtual machine(VM) (redhat6.3_64bit) using OVMF in XEN4.6.
 
 And the memory of the VM is 64G.
 
But I only got 3.5G inside the VM using free.
 
There is a same problem in KVM too.

I don't have a Xen environment to test this. CC'ing Xen devel.

I checked on KVM (upstream OVMF, RHEL-7.1.z host, RHEL-6.5 guest with
5GB RAM). I cannot reproduce the issue; free in the guest reports the
RAM correctly.

Laszlo

 
   
 
total   used   free shared   
 buffers cached
 
  Mem:   3715640 4959163219724  0 
 22060 175136
 
  -/+ buffers/cache: 2987203416920
 
  Swap:  4046840  04046840
 
 
 
in the host using xl list to check:
 
  NameID   Mem VCPUs 
 State   Time(s)
 
  Domain-0 0   305516
 r- 861.2
 
  redhat   4   65536
 2 r-   5.9
 
  
 
  
 
Any thought on this?
 
Any help will be appreciated.
 
If you need some other information, please let me know. :)
 
  
 
  Thanks!
 
  -mao
 
 
 
 --
 
 
 
 ___
 edk2-devel mailing list
 edk2-de...@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/edk2-devel
 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] Question about PEX boot on Xen with OVMF as bios

[Laszlo Ersek]

On 05/25/15 03:50, lidonglin wrote:
 Hi all:

 Recentlly, I want to use PXE boot on Xen with OVMF as bios. At
 beginning, I just add rtl8139 as guest nic device, and I compile a
 release ovmf. When I enter into uefi, I can't find network boot menu.
 According to edk2/OvmfPkg/README file, I know there is a virtio-net
 driver build into ovmf. So I replace rtl8139 with virtio-net. When I
 enter into uefi boot menu again. I see the network boot entry, I'm
 very happy. But after I choose network boot entry, uefi can't display
 pxe boot process, only black sceen with one while dot at the
 beginning of the screen. I try e1000 according to edk2/OvmfPkg/README
 file, and I get the same result. Except e1000 and virtio-net, I can't
 see the network boot entry if I use any other nics. Who can tell me
 how to use pxe boot on Xen with ovmf. Thanks.

(1) The dots that you mention are progress info from the higher level
edk2 network / PXE stack. I can't recall the details without looking at
the code, but if you see at least one dot, that's a sign that PXE boot
is being attempted.

(2) The only SNP (Simple Network Protocol) driver that OVMF contains,
when built purely from the upstream repo, is for the virtio-net device
of QEMU.

I doubt that you can use virtio devices on a Xen host.

(3) Spelling out a special case of (2) -- there's no xen-netfront driver
in OVMF.

(4) One possibility I can see for what you want to do is:
- Configure the e1000 device model for your guest
- Build OVMF as described in OvmfPkg/README, near E1000_ENABLE.
  This requires downloading a proprietary, non-redistributable driver
  binary from Intel.

(5) Another possibility is to use the iPXE drivers (PCI oproms) bundled
with upstream qemu. You'd have to build a recent qemu checkout, and even
so, I'm unsure how PCI oproms are supposed to work on Xen.

Since the iPXE bundle in QEMU provides a UEFI driver for rtl8139, and
you tried that, and it failed, I'm thinking that you either used a too
old qemu, or that this approach is not viable on Xen.

(6) Assuming you get the guest set up alright (correct device model
selected, appropriate driver available etc), it's still 99% certain that
your initial host network config will not be suitable for PXE booting a
guest with the edk2 stack.

In my experience the biggest hurdle in PXE-booting with edk2 has
consistently been: firewall rules, bridge setup, DHCP setup, PXE/TFTP
setup, etc. Tcpdump and the relevant networking specs usually help.

Thanks
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] 答复: Windows 2008 r2 smp guest booting hang with viridian=true on ovmf(xen latest version 4.5.1-rc1 + latest edk2)

[Laszlo Ersek]

On 05/20/15 09:24, Fanhenglong wrote:
 Can anyone have idea about how to boot window 2008 r2 smp guest in ovmf
 with viridian flag is true?

I had to confirm first that viridian means Hyper-V,
http://en.wikipedia.org/wiki/Hyper-V:

  Hyper-V, codenamed Viridian, ...

With that out of the way, I can refer you to

  https://bugzilla.redhat.com/show_bug.cgi?id=1185253

Short version: don't set the viridian flag; the guest you're trying to
run like that was never meant to be run on Hyper-V.

Thanks
Laszlo

 *发件人:*Fanhenglong
 *发送时间:*2015年5月19日23:22
 *收件人:*xen-devel@lists.xen.org
 *抄送:*'k...@xen.org'; 'paul.durr...@citrix.com'; 'jbeul...@suse.com';
 edk2-de...@lists.sourceforge.net; Hanweidong (Randy); Liuqiming (John);
 Liuqiming (John)
 *主题:*Windows 2008 r2 smp guest booting hang with viridian=true on
 ovmf(xen latest version 4.5.1-rc1 + latest edk2)
 
  
 
 Hi all,
 

 
 I have test win2008 r2 guest on ovmf with xen latest version + edk2 latest
 
 Xen : 4.5.1-rc1
 http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=0c4e0ef608c98abef6220b0b027d9ce8ec65fd5f
 
 Edk2 :  e2ab3f819f4e8165c24bd6f4fdc24ef17bdf458b (date:2015/5/18)
 
 and come across a problem:
 
 when the viridian flag is true,win2008 r2 guest can boot success with
 unique processor, but will hang with smp processor on ovmf;
 
 the viridian flag is false, win2008 r2 guest can boot success both in
 unique and smp processor on ovmf;
 
  
 
 if win2008 r2 with viridian=faulse, it may bring 0x101 bluescreen
 
 http://old-list-archives.xenproject.org/archives/html/xen-users/2009-07/msg00661.html
 
  
 
 I try to resolve the problem,
 
 I also run the same testcase on kvm and vmvare ,vm also have the same
 question, vmare is ok;
 
 so I print the cupid function return value in vmvare guest os,
 
 the below table show the detailed information in vmvare guest os,
 
 get cpu id 0 : 000b 756e6547 6c65746e 49656e69
 
 get cpu id 1 : 000106a5 00010800 80982201 0fabfbff
 
 get cpu id 2 : 55035a01 00f0b2e4  09ca212c
 
 get cpu id 3 :    
 
 get cpu id 4 :    
 
 get cpu id 5 :    
 
 get cpu id 4000 : 4010 61774d56 4d566572 65726177
 
 get cpu id 4001 :    
 
 get cpu id 4002 :    
 
 get cpu id 4003 :    
 
 get cpu id 4004 :    
 
 get cpu id 4005 :    
 
 get cpu id 4006 :    
 
 get cpu id 4070 :   00ac 0012
 
 get cpu id 4071 :   00ac 0012
 
 get cpu id 4072 :   00ac 0012
 
 get cpu id 4073 :   00ac 0012
 
 get cpu id 4100 :   00ac 
 
 get cpu id 4101 :   00ac 
 
 get cpu id 4102 :   00ac 
 
 get cpu id 4103 :   00ac 
 
 get cpu id 4104 :   00ac 
 
 get cpu id 4105 :   00ac 
 
 get cpu id 4106 :   00ac 
 
 get cpu id 8000 : 8008   
 
 get cpu id 8001 :   0001 2810
 
 get cpu id 8002 : 65746e49 2952286c 6f655820 2952286e
 
 get cpu id 8003 : 55504320 20202020 20202020 45202020
 
 get cpu id 8004 : 30323535 20402020 37322e32 007a4847
 
 get cpu id 8005 :    
 
 get cpu id 8006 :   01006040 
 
 get cpu id 8007 :    0100
 
 get cpu id 8008 : 3028   
 
 get cpu id 8009 :   00ac 
 
  
 
  
 
 I modified cpuid_viridian_leaves function in 
 xen/arch/x86/hvm/viridian.c (as the following red bold code)
 
 to return value 0 for cupid (function=4001), and win2008 r2 smp
 guest can boot success on ovmf;
 
  
 
 int cpuid_viridian_leaves(unsigned int leaf, unsigned int *eax,
 
   unsigned int *ebx, unsigned int *ecx,
 
   unsigned int *edx)
 
 {
 
 struct domain *d = current-domain;
 
  
 
 if ( !is_viridian_domain(d) )
 
 return 0;
 
  
 
 leaf -= 0x4000;
 
 if ( leaf  6 )
 
 return 0;
 
  
 
 *eax = *ebx = *ecx = *edx = 0;
 
 switch ( leaf )
 
 {
 
 case 0:
 
 *eax = 0x4006; /* Maximum leaf */
 
 *ebx = 0x7263694d; /* Magic numbers  */
 
 *ecx = 0x666F736F;
 
 *edx = 0x76482074;
 
 break;
 
 case 1:
 
 //original code **eax = 0x31237648; /* Version number */*
 
 *   *eax = 0; //code after modified*
 
 break;
 
  
 
   
 
based on hyperv spec, Microsoft Hypervisor CPUID Leaves,
 
0x4001
 
 

Re: [Xen-devel] [edk2] Windows 8 64bit Guest BSOD when using OVMF to boot and *install* from CDROM(when configured with more than 4G memory)

[Laszlo Ersek]

On 05/07/15 08:47, lidonglin wrote:
 Dear all：
   New issue：
   Guest BSOD and restart when using OVMF to boot and install windows8 
 64bit OS(which owns more than 4G memmory)。
 My environment as below:
 xen 4.5.0
 qemu 2.2.1
 ovmf git clone from git://xenbits.xen.org/ovmf.git (commit 
 a065efc7c7ce8bb3e5cb3e463099d023d4a92927)
 
 I just git clone xen from git://xenbits.xen.org/xen.git. configure it and 
 parameters as below:
 ./configure --prefix=/usr/ --libdir=/usr/lib/  --enable-ovmf then make  
 make install, after that I reboot my host OS(SuSE 11.3).
 I write a cfg file win8.cfg as below:
 builder = hvm
 name = win8
 memory = 2048
 maxmem = 2048
 vcpus = 4
 bios = ovmf
 boot = d
 disk = [ 
 '/test/Windows8-ReleasePreview-64bit-ChineseSimplified.iso,,hdc,cdrom','/test/win8.img,raw,xvda,rw'
  ] usb = 1 usbdevice=tablet
 vnc = 1
 vnclisten = '9.61.1.3'
 vncdisplay = 0
 
 # xl create win8.cfg
 after the command I use vnc client to connect guest, win8 guest works 
 normally.
 then I modify the memory size and change it to 8192MB, save and start win8 
 guest again.
 after ovmf bios logo, windows8 logo appears, go on for a while, the guest 
 stops and restart, then stop （sometimes BSOD，but no error code on the screen) 
 and restart repeat the process
 
 I tried some different memory sizes, the result is guest can work normally 
 when it has 4320MB memory at most, but it stop and restart when it has lager 
 than 4320MB memory

CC'ing the xen-devel mailing list, as I have no environment to reproduce
this in. (Plus, you are cloning a git repo that may or may not be
identical to the (semi-)official edk2 git repo.)

Thanks
Laszlo


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] Windows 8 64bit Guest BSOD when using OVMF to boot and *install* from CDROM(when configured with more than 4G memory)

[Laszlo Ersek]

On 05/07/15 11:29, Ian Campbell wrote:
 On Thu, 2015-05-07 at 09:02 +0200, Laszlo Ersek wrote:
 (Plus, you are cloning a git repo that may or may not be
 identical to the (semi-)official edk2 git repo.)
 
 FWIW git://xenbits.xen.org/ovmf.git is a direct descendant of the
 https://github.com/tianocore/edk2.git (which I hope is the
 (semi-)official repo!)

It is, yes.

Thanks
Laszlo

 and all that happens is that changes get run
 through our automated smoke tests before they are pushed to the xenbits
 tree to use as a baseline for other testing.
 
 IOW it tracks upstream but may be a little behind the tip depending on
 how our tests are going (e.g. they are a bit backlogged right now since
 we moved to a new hosting facility).
 
 Ian.
 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 00/29] Xen/ARM guest support

[Laszlo Ersek]

On 02/24/15 19:37, Ard Biesheuvel wrote:
 On 24 February 2015 at 18:34, Laszlo Ersek ler...@redhat.com wrote:
 On 02/24/15 19:02, Ard Biesheuvel wrote:

 Changes since v4:
 - rename InterlockedCompareExchange16 () patch as suggested by Jordan, and 
 added
   his ack
 - fix a bug spotted by Anthony in the TestAndClearBit () implementation
 - added more acks and R-b's

 - Are there any patches missing review tags?
 
 There is just one patch, #23, which had a bug so I was hoping Anthony
 would add his R-b to the now fixed version.
 The InterlockedCompareExchange16() has Jordan's ack, but no reply yet
 from Michael Kinney.
 
 - Who should push this once everything is reviewed?

 
 Good question. Are you volunteering? :-)

Yes. Kick me when you have a public branch with the final review tags added.

Thanks
Laszlo


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 00/29] Xen/ARM guest support

[Laszlo Ersek]

On 02/24/15 19:02, Ard Biesheuvel wrote:

 Changes since v4:
 - rename InterlockedCompareExchange16 () patch as suggested by Jordan, and 
 added
   his ack
 - fix a bug spotted by Anthony in the TestAndClearBit () implementation
 - added more acks and R-b's

- Are there any patches missing review tags?
- Who should push this once everything is reviewed?

Thanks
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 00/29] Xen/ARM guest support

[Laszlo Ersek]

On 02/24/15 20:01, Ard Biesheuvel wrote:
 On 24 February 2015 at 18:41, Laszlo Ersek ler...@redhat.com wrote:
 On 02/24/15 19:37, Ard Biesheuvel wrote:
 On 24 February 2015 at 18:34, Laszlo Ersek ler...@redhat.com wrote:
 On 02/24/15 19:02, Ard Biesheuvel wrote:

 Changes since v4:
 - rename InterlockedCompareExchange16 () patch as suggested by Jordan, 
 and added
   his ack
 - fix a bug spotted by Anthony in the TestAndClearBit () implementation
 - added more acks and R-b's

 - Are there any patches missing review tags?

 There is just one patch, #23, which had a bug so I was hoping Anthony
 would add his R-b to the now fixed version.
 The InterlockedCompareExchange16() has Jordan's ack, but no reply yet
 from Michael Kinney.

 - Who should push this once everything is reviewed?


 Good question. Are you volunteering? :-)

 Yes. Kick me when you have a public branch with the final review tags added.

 
 Grr. Patch #13 is authored jointly by Olivier and myself, and touches
 only ARM specific code under MdePkg/
 I guess that needs someone else's ack as well?
 
 Anyways, the branch is here
 https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/linaro-topic-xen
 
 with acks/r-b's on all patches except #13

If Olivier is okay with patch #13, then I don't think that should be a
worry. However we should await Michael's feedback for patch #14. Please
write him an email directly, with a distinct subject.

Thanks
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] [PATCH] OvmfPkg: AcpiPlatformDxe: PCI enumeration may be disabled

[Laszlo Ersek]

On 02/12/15 21:53, Jordan Justen wrote:
 I think gEfiPciEnumerationCompleteProtocolGuid should be installed by
 MdeModulePkg/Bus/Pci/PciBusDxe, even when PcdPciDisableBusEnumeration
 is set.
 
 Ray's main feedback seemed to be that we need to make sure PciBusDxe
 only installs the protocol once. (I'll also reply to the other related
 patch thread.)

First, I now agree that this patch of mine should not go in, hence:

Self-NAK

Second, I tend to disagree that that
gEfiPciEnumerationCompleteProtocolGuid should be installed even if full
enumeration was eschewed. This might slightly change the de-facto
meaning of the protocol (because no resource allocation took place). In
general I think we should not try to touch
MdeModulePkg/Bus/Pci/PciBusDxe for our need here.

So let's think again what we need.

We want to delay the download and installation of ACPI tables on virt
platforms until PCI enumeration is complete, *except* in some cases:

(1) When OVMF runs on Xen.

In that case PcdPciDisableBusEnumeration is TRUE, and the PCI bus driver
does not install gEfiPciEnumerationCompleteProtocolGuid (in my opinion:
correctly, because no resource allocation takes place, which is the
de-facto meaning of the completion protocol).

This means that the depex in
OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf is no longer correct:

[Depex]
  gEfiAcpiTableProtocolGuid AND gEfiPciEnumerationCompleteProtocolGuid

(2) When the platform in question lacks PCI.

Right now this means ArmVirtualizationQemu. However, that is about to
change (I've mostly ported PCI support to ArmVirtualizationQemu;
virtio-pci, USB keyboard, std-VGA work). Importantly, presence of PCI on
ARM will become a *dynamic* question, dependent on the QEMU version.
Current master QEMU does not provide PCI hardware for arm/mach-virt, but
Alex Graf's patches in Peter Maydell's target-arm.next branch do, and so
will master soon.

This means that the depex in
OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf will also break:

[Depex]
  gEfiAcpiTableProtocolGuid

[Depex.IA32, Depex.X64]
  gEfiPciEnumerationCompleteProtocolGuid

because on ARM we might or might not want to wait for enumeration
completion dependent on whether the DTB ultimately describes a PCI root
bridge or not.

So here's what I propose. (Again, the above is *all* motivated by
OvmfPkg/AcpiPlatformDxe/.) In my PCI-for-ArmVirtualizationQemu patchset,
I will introduce a new protocol GUID (with NULL structure) that will
simply say OvmfPkg's AcpiPlatformDxe should not wait for PCI
enumeration. Then, *both* INF files under OvmfPkg/AcpiPlatformDxe shall
receive the following depex:

[Depex]
  gEfiAcpiTableProtocolGuid AND
  (gEfiPciEnumerationCompleteProtocolGuid OR
   gOvmfAcpiPlatformNoPciEnumerationProtocolGuid
   )

Then each particular platform driver shall unblock AcpiPlatformDxe in
its own way:

- OVMF on QEMU will do nothing special, it'll just go with the usual
  gEfiPciEnumerationCompleteProtocolGuid, installed by PciBusDxe.

- OVMF on Xen will install gOvmfAcpiPlatformNoPciEnumerationProtocolGuid

  -- Wei, could you post a patch for this later? I think the protocol
  should be installed in XenBusDxeDriverBindingStart(), when it
  succeeds.

  It would be probably prudent to coordinate with Ard, wrt. Ard's series
  that brings Xen to ArmVirtualizationQemu.

- In my PCI-for-ArmVirtualizationQemu series, I'll install
  gOvmfAcpiPlatformNoPciEnumerationProtocolGuid in case PCI is
  unavailable on the particular QEMU version.

My main point is, our *real* target is OvmfPkg/AcpiPlatformDxe here, and
the conditions whether to delay or not to delay its work until PCI
enumeration is complete are platform dependent and *dynamic*. We should
let all platform-specific drivers decide for themselves, and we should
steer clear of drivers that are central to edk2, like PciBusDxe.

What do you guys think?

Thanks!
Laszlo

 
 -Jordan
 
 On 2015-02-12 04:16:07, Laszlo Ersek wrote:
 SVN r16411 delayed ACPI table installation until PCI enumeration was
 complete, because on QEMU the ACPI-related fw_cfg files should only be
 downloaded after PCI enumeration.

 However, InitializeXen() in OvmfPkg/PlatformPei/Xen.c sets
 PcdPciDisableBusEnumeration to TRUE. This causes
 PciBusDriverBindingStart() in MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c to
 set gFullEnumeration to FALSE, which in turn makes PciEnumerator() in
 MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c branch to
 PciEnumeratorLight(). The installation of
 EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL at the end of PciEnumerator() is not
 reached.

 Which means that starting with SVN r16411, AcpiPlatformDxe is never
 dispatched on Xen.

 This patch replaces the EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL depex with a
 matching protocol registration callback for the PCI enumeration enabled
 (ie. QEMU) case. When PCI enumeration is disabled (ie. when running on
 Xen), AcpiPlatformDxe doesn't wait for
 EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL.

 Contributed-under: TianoCore

Re: [Xen-devel] [edk2] [PATCH] OvmfPkg: AcpiPlatformDxe: PCI enumeration may be disabled

[Laszlo Ersek]

On 02/14/15 21:03, Jordan Justen wrote:
 On 2015-02-14 08:38:37, Laszlo Ersek wrote:
 On 02/12/15 21:53, Jordan Justen wrote:
 I think gEfiPciEnumerationCompleteProtocolGuid should be installed by
 MdeModulePkg/Bus/Pci/PciBusDxe, even when PcdPciDisableBusEnumeration
 is set.

 Ray's main feedback seemed to be that we need to make sure PciBusDxe
 only installs the protocol once. (I'll also reply to the other related
 patch thread.)

 First, I now agree that this patch of mine should not go in, hence:

 Self-NAK

 Second, I tend to disagree that that
 gEfiPciEnumerationCompleteProtocolGuid should be installed even if full
 enumeration was eschewed. This might slightly change the de-facto
 meaning of the protocol (because no resource allocation took place).
 
 De-facto seems the correct term here, since the PI1.2 spec says very
 little about the protocol.
 
 My interpretation of the protocol is that it is a signal that the EFI
 knows about the basic PCI topology, and has installed most PciIo
 instances.
 
 Maybe PcdPciDisableBusEnumeration wasn't the best name. Perhaps
 PcdPciBusPreEnumerated would have been better.
 
 At any rate, in the case of Xen, the hypervisor has pre-enumerated the
 bus. PciBusDxe uses this and 'enumerates' PCI devices by simply
 scanning the pre-enumerated topology.
 
 So, I still think PciBusDxe should install
 gEfiPciEnumerationCompleteProtocolGuid, because it still seems like it
 acurately reflects the phase of the boot process.
 
 Regarding the ACPI tables issue, would a callback for the ReadyToBoot
 event work?

EFI_EVENT_GROUP_READY_TO_BOOT

  This event group is notified by the system when the Boot Manager is
  about to load and execute a boot option.

(1) As far as I understand, if you boot a UEFI application, then exit
it, and boot something else, then the event group will be signalled each
time.

We could use a static variable in AcpiPlatformDxe to avoid trying to
install again and again, but it wouldn't be nice IMHO.

This is the secondary reason I'm not enthusiastic about
EFI_EVENT_GROUP_READY_TO_BOOT. :)

(2) The main reason is different: in both OVMF and ArmVirtualizationQemu
we can boot a kernel directly, taken from QEMU. That happens without
EFI_EVENT_GROUP_READY_TO_BOOT being signalled.

However, the kernel booted thus should have both ACPI tables and
configured PCI devices (if there is a PCI host). In OVMF this is ensured by:

PlatformBdsPolicyBehavior()
  PlatformBdsConnectSequence()
BdsLibConnectAll()
  TryRunningQemuKernel()

where the BdsLibConnectAll() call listed above will cover the
enumeration, and trigger the dependent ACPI table installation as well,
before we go to the kernel.

One idea could be to signal EFI_EVENT_GROUP_READY_TO_BOOT ourselves,
before booting the kernel; however this event group seems quite tied to
the Boot Manager itself (see again its definition above).

I'll post my patch series soon; my idea that is relevant for this
discussion is at its beginning (and a later patch also displays how I
mean it to be used). We can discuss it there too if you like.

Thanks
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] MdeModulePkg: mark completion of PCI enumeration in PciEnumeratorLight

[Laszlo Ersek]

On 02/11/15 21:23, Wei Liu wrote:
 I had an issue when trying to boot Xen HVM guest with latest OVMF
 master. Guest crashed with memory violation, and the bisection pointed
 to 66b280df2 (OvmfPkg: AcpiPlatformDxe: make dependency on PCI
 enumeration explicit). That commit made AcpiPlatformDxe depend on PCI
 enumeration using gEfiPciEnumerationCompleteProtocolGuid, which is a
 very reasonable change.
 
 The real culprit is that Xen HVM is using PciEnumeratorLight which
 doesn't install gEfiPciEnumerationCompleteProtocolGuid. This, in
 combination with 66b280df2, makes AcpiPlatformDxe not able to be loaded,
 resulting in guest crash.
 
 The fix is to install gEfiPciEnumerationCompleteProtocolGuid in
 PciEnumeratorLight.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Wei Liu wei.l...@citrix.com
 Cc: Feng Tian feng.t...@intel.com
 Cc: Anthony Perard anthony.per...@citrix.com
 Cc: Laszlo Ersek ler...@redhat.com
 Cc: Jordan Justen jordan.l.jus...@intel.com
 ---
  MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c | 15 ++-
  1 file changed, 14 insertions(+), 1 deletion(-)
 
 diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c 
 b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
 index 9e7ac74..7659585 100644
 --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
 +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
 @@ -2256,6 +2256,7 @@ PciEnumeratorLight (
  {
  
EFI_STATUSStatus;
 +  EFI_HANDLEHostBridgeHandle;
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL   *PciRootBridgeIo;
PCI_IO_DEVICE *RootBridgeDev;
UINT16MinBus;
 @@ -2288,6 +2289,11 @@ PciEnumeratorLight (
  return Status;
}
  
 +  //
 +  // Get the host bridge handle
 +  //
 +  HostBridgeHandle = PciRootBridgeIo-ParentHandle;
 +
Status = PciRootBridgeIo-Configuration (PciRootBridgeIo, (VOID **) 
 Descriptors);
  
if (EFI_ERROR (Status)) {
 @@ -2348,7 +2354,14 @@ PciEnumeratorLight (
  Descriptors++;
}
  
 -  return EFI_SUCCESS;
 +  Status = gBS-InstallProtocolInterface (
 +  HostBridgeHandle,
 +  gEfiPciEnumerationCompleteProtocolGuid,
 +  EFI_NATIVE_INTERFACE,
 +  NULL
 +  );
 +
 +  return Status;
  }
  
  /**
 

I think this could result in several installations of
gEfiPciEnumerationCompleteProtocolGuid. See the beginning of the
PciEnumerator() function.

If gFullEnumeration is TRUE to begin with (which is the QEMU case), then
the protocol will be installed at the end of PciEnumerator() first. At
that point we flip gFullEnumeration to FALSE, which implies that further
invocations of PciEnumerator() are possible and allowed. So at the next
call gFullEnumeration will be false, ie. we'll call
PciEnumeratorLight(). With the above patch PciEnumeratorLight() would
add the 2nd (and possibly further) instances of
EfiPciEnumerationCompleteProtocol.

I'll submit an alternative patch for OvmfPkg soon.

Thanks
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] OvmfPkg: AcpiPlatformDxe: PCI enumeration may be disabled

[Laszlo Ersek]

SVN r16411 delayed ACPI table installation until PCI enumeration was
complete, because on QEMU the ACPI-related fw_cfg files should only be
downloaded after PCI enumeration.

However, InitializeXen() in OvmfPkg/PlatformPei/Xen.c sets
PcdPciDisableBusEnumeration to TRUE. This causes
PciBusDriverBindingStart() in MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c to
set gFullEnumeration to FALSE, which in turn makes PciEnumerator() in
MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c branch to
PciEnumeratorLight(). The installation of
EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL at the end of PciEnumerator() is not
reached.

Which means that starting with SVN r16411, AcpiPlatformDxe is never
dispatched on Xen.

This patch replaces the EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL depex with a
matching protocol registration callback for the PCI enumeration enabled
(ie. QEMU) case. When PCI enumeration is disabled (ie. when running on
Xen), AcpiPlatformDxe doesn't wait for
EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
 OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf |  4 +-
 OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c  | 84 +++--
 2 files changed, 72 insertions(+), 16 deletions(-)

diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf 
b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
index 53292bf..6b2c9d2 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
@@ -56,16 +56,18 @@
 
 [Protocols]
   gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
+  gEfiPciEnumerationCompleteProtocolGuid# PROTOCOL SOMETIMES_CONSUMED
 
 [Guids]
   gEfiXenInfoGuid
 
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiTableStorageFile
+  gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration
   gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
   gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress
 
 [Depex]
-  gEfiAcpiTableProtocolGuid AND gEfiPciEnumerationCompleteProtocolGuid
+  gEfiAcpiTableProtocolGuid
 
diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c 
b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c
index 11f0ca8..9823eba 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c
@@ -12,6 +12,7 @@
 
 **/
 
+#include Protocol/PciEnumerationComplete.h
 #include AcpiPlatform.h
 
 EFI_STATUS
@@ -221,6 +222,47 @@ FindAcpiTablesInFv (
   return EFI_SUCCESS;
 }
 
+STATIC
+EFI_STATUS
+EFIAPI
+InstallTables (
+  VOID
+  )
+{
+  EFI_STATUS  Status;
+  EFI_ACPI_TABLE_PROTOCOL *AcpiTable;
+
+  Status = gBS-LocateProtocol (gEfiAcpiTableProtocolGuid,
+  NULL /* Registration */, (VOID **)AcpiTable);
+  if (EFI_ERROR (Status)) {
+return EFI_ABORTED;
+  }
+
+  if (XenDetected ()) {
+Status = InstallXenTables (AcpiTable);
+  } else {
+Status = InstallAllQemuLinkedTables (AcpiTable);
+  }
+
+  if (EFI_ERROR (Status)) {
+Status = FindAcpiTablesInFv (AcpiTable);
+  }
+
+  return Status;
+}
+
+STATIC
+VOID
+EFIAPI
+OnPciEnumerated (
+  IN EFI_EVENT Event,
+  IN VOID  *Context
+  )
+{
+  InstallTables ();
+  gBS-CloseEvent (Event);
+}
+
 /**
   Entrypoint of Acpi Platform driver.
 
@@ -239,31 +281,43 @@ AcpiPlatformEntryPoint (
   IN EFI_SYSTEM_TABLE   *SystemTable
   )
 {
-  EFI_STATUS Status;
-  EFI_ACPI_TABLE_PROTOCOL*AcpiTable;
+  EFI_STATUS Status;
+  VOID   *Interface;
+  EFI_EVENT  PciEnumerated;
+  VOID   *Registration;
 
   //
-  // Find the AcpiTable protocol
+  // If PCI enumeration has been disabled, or it has already completed, install
+  // the tables at once, and let the entry point's return code reflect the full
+  // functionality.
   //
-  Status = gBS-LocateProtocol (
-  gEfiAcpiTableProtocolGuid,
-  NULL,
-  (VOID**)AcpiTable
-  );
-  if (EFI_ERROR (Status)) {
-return EFI_ABORTED;
+  if (PcdGetBool (PcdPciDisableBusEnumeration)) {
+return InstallTables ();
   }
 
-  if (XenDetected ()) {
-Status = InstallXenTables (AcpiTable);
-  } else {
-Status = InstallAllQemuLinkedTables (AcpiTable);
+  Status = gBS-LocateProtocol (gEfiPciEnumerationCompleteProtocolGuid,
+  NULL /* Registration */, Interface);
+  if (!EFI_ERROR (Status)) {
+return InstallTables ();
   }
+  ASSERT (Status == EFI_NOT_FOUND);
 
+  //
+  // Otherwise, delay the installation until PCI enumeration is complete. The
+  // entry point's return status will only reflect the callback setup.
+  //
+  Status = gBS-CreateEvent (EVT_NOTIFY_SIGNAL, TPL_CALLBACK, OnPciEnumerated,
+  NULL /* Context */, PciEnumerated);
   if (EFI_ERROR (Status)) {
-Status = FindAcpiTablesInFv (AcpiTable);
+return Status;
   }
 
+  Status = gBS-RegisterProtocolNotify

Re: [Xen-devel] [PATCH] OvmfPkg: AcpiPlatformDxe: PCI enumeration may be disabled

[Laszlo Ersek]

On 02/12/15 13:29, Wei Liu wrote:
 On Thu, Feb 12, 2015 at 01:16:07PM +0100, Laszlo Ersek wrote:
 SVN r16411 delayed ACPI table installation until PCI enumeration was
 complete, because on QEMU the ACPI-related fw_cfg files should only be
 downloaded after PCI enumeration.

 However, InitializeXen() in OvmfPkg/PlatformPei/Xen.c sets
 PcdPciDisableBusEnumeration to TRUE. This causes
 PciBusDriverBindingStart() in MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c to
 set gFullEnumeration to FALSE, which in turn makes PciEnumerator() in
 MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c branch to
 PciEnumeratorLight(). The installation of
 EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL at the end of PciEnumerator() is not
 reached.

 Which means that starting with SVN r16411, AcpiPlatformDxe is never
 dispatched on Xen.

 This patch replaces the EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL depex with a
 matching protocol registration callback for the PCI enumeration enabled
 (ie. QEMU) case. When PCI enumeration is disabled (ie. when running on
 Xen), AcpiPlatformDxe doesn't wait for
 EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Laszlo Ersek ler...@redhat.com
 
 This patch fixes the bug I have. Thanks!
 
 Tested-by: Wei Liu wei.l...@citrix.com

Thanks. If Jordan is okay with the patch too, I'll push it.

Sorry about the regression, too.

Cheers
Laszlo


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 18/27] Ovmf/Xen: add separate driver for Xen PCI device

[Laszlo Ersek]

On 02/03/15 20:20, Ard Biesheuvel wrote:
 Prepare for making XenBusDxe suitable for use with non-PCI devices
 (such as the DT node exposed by Xen on ARM) by introducing a separate
 DXE driver that binds to the Xen virtual PCI device and exposes the
 abstract XENIO_PROTOCOL for XenBusDxe to bind against.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  OvmfPkg/XenIoPciDxe/XenIoPciDxe.c   | 367 
 
  OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf |  45 +
  2 files changed, 412 insertions(+)
  create mode 100644 OvmfPkg/XenIoPciDxe/XenIoPciDxe.c
  create mode 100644 OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf

Reviewed-by: Laszlo Ersek ler...@redhat.com

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 25/27] ArmVirtualizationPkg: add XenIoMmioLib

[Laszlo Ersek]

On 02/03/15 20:20, Ard Biesheuvel wrote:
 This adds a XenIoMmioLib declaration and implementation that can
 be invoked to install the XENIO_PROTOCOL and a corresponding
 grant table address on a EFI handle.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  OvmfPkg/Include/Library/XenIoMmioLib.h|  64 ++
  OvmfPkg/Library/XenIoMmioLib/XenIoMmioLib.c   | 166 
 ++
  OvmfPkg/Library/XenIoMmioLib/XenIoMmioLib.inf |  39 ++
  OvmfPkg/OvmfPkg.dec   |   4 +
  4 files changed, 273 insertions(+)
  create mode 100644 OvmfPkg/Include/Library/XenIoMmioLib.h
  create mode 100644 OvmfPkg/Library/XenIoMmioLib/XenIoMmioLib.c
  create mode 100644 OvmfPkg/Library/XenIoMmioLib/XenIoMmioLib.inf

There are two occurrences of the typo if if in this patch. In case you
send a v4, please fix that.

Reviewed-by: Laszlo Ersek ler...@redhat.com

I'm done with the v3 review; you addressed all my v2 comments.

Thanks!
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 22/27] Ovmf/Xen: add Xen PV console SerialPortLib driver

[Laszlo Ersek]

On 02/03/15 20:20, Ard Biesheuvel wrote:
 This implements a SerialPortLib instance that wires up to the
 PV console ring used by domU guests. Also imports the required
 upstream Xen io/console.h header.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Reviewed-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  OvmfPkg/Include/IndustryStandard/Xen/io/console.h  |  51 +++
  .../XenConsoleSerialPortLib.c  | 156 
 +
  .../XenConsoleSerialPortLib.inf|  35 +
  3 files changed, 242 insertions(+)
  create mode 100644 OvmfPkg/Include/IndustryStandard/Xen/io/console.h
  create mode 100644 
 OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c
  create mode 100644 
 OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf

You added the comment I asked for, hence

Acked-by: Laszlo Ersek ler...@redhat.com


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 23/27] Ovmf/Xen: implement dummy RealTimeClockLib for Xen

[Laszlo Ersek]

On 02/03/15 20:20, Ard Biesheuvel wrote:
 This implements a dummy RealTimeClockLib for Xen, as there is no
 guest interface to access the time kept by Xen that can be shared
 between UEFI and the OS.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  .../XenRealTimeClockLib/XenRealTimeClockLib.c  | 196 
 +
  .../XenRealTimeClockLib/XenRealTimeClockLib.inf|  38 
  2 files changed, 234 insertions(+)
  create mode 100644 
 ArmPlatformPkg/ArmVirtualizationPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
  create mode 100644 
 ArmPlatformPkg/ArmVirtualizationPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf

Moved to ArmPlatformPkg/ArmVirtualizationPkg/Library/, hence

Acked-by: Laszlo Ersek ler...@redhat.com


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 27/29] ArmVirtualizationPkg: add XenIoMmioLib

[Laszlo Ersek]

On 01/26/15 20:03, Ard Biesheuvel wrote:

 +EFI_STATUS
 +XenIoMmioInstall (
 +  IN  EFI_HANDLE  *Handle,
 +  IN  UINT64  GrantTableAddress
 +  );

Sorry I had another (pedantic) remark here -- consider
EFI_PHYSICAL_ADDRESS instead of UINT64. (It looks better and that's
what's in your protocol struct anyway, IIRC.)

Thanks
Laszlo


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 27/29] ArmVirtualizationPkg: add XenIoMmioLib

[Laszlo Ersek]

On 02/03/15 12:45, Laszlo Ersek wrote:
 comments below
 
 On 01/26/15 20:03, Ard Biesheuvel wrote:

 +EFI_STATUS
 +XenIoMmioInstall (
 +  IN  EFI_HANDLE  *Handle,
 +  IN  UINT64  GrantTableAddress
 +  )
 +{
 +  EFI_STATUS Status;
 +  XENIO_PROTOCOL *XenIo;
 +  XENBUS_ROOT_DEVICE_PATH*XenBusDevicePath;
 +
 +  ASSERT (Handle != NULL);
 
 (4) This is wrong. (I'm not sure how you are using the library in the
 following patches, but this in itself does look wrong.)

Heh, I tricked myself. This ASSERT() is valid. I missed you weren't
saying *Handle.

However, I believe the following remains valid from my point (4):

 (Note that the uninstall functions can't null the Handle parameter in
 that case -- which means that you should save a copy of the incoming
 handle, and restore it at the end when something fails. If it was
 non-NULL initially, nothing will change, but if it was NULL initially,
 you have to reset it to NULL.)

Thanks
Laszlo


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 29/29] ArmVirtualizationPkg: add platform description for Xen guests

[Laszlo Ersek]

On 01/26/15 20:03, Ard Biesheuvel wrote:
 This adds the .dsc and .fdf descriptions to build a UEFI image that
 is bootable by a Xen guest on 64-bit ARM (AArch64)
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationXen.dsc | 279 
 +++
  ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationXen.fdf | 337 
 +
  2 files changed, 616 insertions(+)
 
 diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationXen.dsc 
 b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationXen.dsc
 new file mode 100644
 index ..bcc9742c6828
 --- /dev/null
 +++ b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationXen.dsc
 @@ -0,0 +1,279 @@
 +#
 +#  Copyright (c) 2011-2013, ARM Limited. All rights reserved.
 +#  Copyright (c) 2014, Linaro Limited. All rights reserved.
 +#
 +#  This program and the accompanying materials
 +#  are licensed and made available under the terms and conditions of the BSD 
 License
 +#  which accompanies this distribution.  The full text of the license may be 
 found at
 +#  http://opensource.org/licenses/bsd-license.php
 +#
 +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
 +#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
 IMPLIED.
 +#
 +#
 +
 +
 +#
 +# Defines Section - statements that will be processed to create a Makefile.
 +#
 +
 +[Defines]
 +  PLATFORM_NAME  = ArmVirtualizationQemu

Wut? :)

 +  PLATFORM_GUID  = 37d7e986-f7e9-45c2-8067-e371421a626c

PLATFORM_GUID shoud be updated as well.

I won't check the rest of the patch now; you got several notes from
Julien. Please eyeball this patch for any leftovers from the QEMU files.
You can add my

Acked-by: Laszlo Ersek ler...@redhat.com

then.

Also, I think I finished reviewing the series. (Some patches I didn't
comment on; I didn't want to review those.)

Thanks!
Laszlo

 +  PLATFORM_VERSION   = 0.1
 +  DSC_SPECIFICATION  = 0x00010005
 +  OUTPUT_DIRECTORY   = Build/ArmVirtualizationXen-$(ARCH)
 +  SUPPORTED_ARCHITECTURES= AARCH64
 +  BUILD_TARGETS  = DEBUG|RELEASE
 +  SKUID_IDENTIFIER   = DEFAULT
 +  FLASH_DEFINITION   = 
 ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationXen.fdf
 +
 +!include ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualization.dsc.inc
 +
 +[LibraryClasses]
 +  
 SerialPortLib|OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf
 +  
 RealTimeClockLib|OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
 +  XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLibArm.inf
 +  
 XenIoMmioLib|ArmPlatformPkg/ArmVirtualizationPkg/Library/XenIoMmioLib/XenIoMmioLib.inf
 +
 +[LibraryClasses.AARCH64]
 +  ArmLib|ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf
 +  ArmCpuLib|ArmPkg/Drivers/ArmCpuLib/ArmCortexAEMv8Lib/ArmCortexAEMv8Lib.inf
 +
 +[LibraryClasses.ARM]
 +  ArmLib|ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.inf
 +  ArmCpuLib|ArmPkg/Drivers/ArmCpuLib/ArmCortexA15Lib/ArmCortexA15Lib.inf
 +
 +[LibraryClasses.common]
 +  # Virtio Support
 +  VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
 +  
 VirtioMmioDeviceLib|OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
 +
 +  
 ArmPlatformLib|ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmXenRelocatablePlatformLib/ArmXenRelocatablePlatformLib.inf
 +  
 ArmPlatformSysConfigLib|ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.inf
 +
 +  TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
 +
 +!ifdef INTEL_BDS
 +  CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
 +  
 GenericBdsLib|IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf
 +  
 PlatformBdsLib|ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
 +  
 CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
 +!endif
 +
 +[LibraryClasses.common.UEFI_DRIVER]
 +  UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
 +
 +[LibraryClasses.AARCH64.SEC]
 +  ArmLib|ArmPkg/Library/ArmLib/AArch64/AArch64LibSec.inf
 +
 +[LibraryClasses.ARM.SEC]
 +  ArmLib|ArmPkg/Library/ArmLib/ArmV7/ArmV7LibSec.inf
 +
 +[BuildOptions]
 +  RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A15 
 -I$(WORKSPACE)/ArmPlatformPkg/ArmVirtualizationPkg/Include
 +  GCC:*_*_ARM_PLATFORM_FLAGS == -mcpu=cortex-a15 
 -I$(WORKSPACE)/ArmPlatformPkg/ArmVirtualizationPkg/Include
 +  GCC:*_*_AARCH64_PLATFORM_FLAGS == 
 -I$(WORKSPACE)/ArmPlatformPkg/ArmVirtualizationPkg/Include

Re: [Xen-devel] [PATCH v2 28/29] ArmVirtualizationPkg/VirtFdtDxe: wire up XenBusDxe to xen, xen DT node

[Laszlo Ersek]

On 01/26/15 20:03, Ard Biesheuvel wrote:
 This patchs adds support to VirtFdtDxe for the Xen DT node which
 contains the base address of the Grant Table. This data is communicated
 to XenBusDxe using a XENIO_PROTOCOL instance.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c   | 23 
 +++
  ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf |  1 +
  2 files changed, 24 insertions(+)
 
 diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c 
 b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
 index 34fac40fa803..1ceb85146430 100644
 --- a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
 +++ b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
 @@ -26,6 +26,7 @@
  #include Library/DxeServicesLib.h
  #include Library/HobLib.h
  #include libfdt.h
 +#include Library/XenIoMmioLib.h
  
  #include Guid/Fdt.h
  #include Guid/VirtioMmioTransport.h
 @@ -49,6 +50,7 @@ typedef enum {
PropertyTypePsci,
PropertyTypeFwCfg,
PropertyTypeGicV3,
 +  PropertyTypeXen,
  } PROPERTY_TYPE;
  
  typedef struct {
 @@ -66,6 +68,7 @@ STATIC CONST PROPERTY CompatibleProperties[] = {
{ PropertyTypePsci,arm,psci-0.2},
{ PropertyTypeFwCfg,   qemu,fw-cfg-mmio},
{ PropertyTypeGicV3,   arm,gic-v3  },
 +  { PropertyTypeXen, xen,xen },
{ PropertyTypeUnknown, }
  };
  
 @@ -332,6 +335,26 @@ InitializeVirtFdtDxe (
}
break;
  
 +case PropertyTypeXen:
 +  ASSERT (Len == 16);
 +
 +  //
 +  // Retrieve the reg base from this node and add it to a
 +  // XENIO_PROTOCOL instance installed on a new handle.
 +  //
 +  RegBase = fdt64_to_cpu (((UINT64 *)RegProp)[0]);
 +  Handle = NULL;
 +  Status = XenIoMmioInstall (Handle, RegBase);
 +  if (EFI_ERROR (Status)) {
 +DEBUG ((EFI_D_ERROR, %a: Failed to install XENIO_PROTOCOL on a new 
 handle 
 +  (Status == %r)\n, __FUNCTION__, Status));

(1) I don't think it's necessary to mention XENIO_PROTOCOL here.
XenIoMmioInstall() does more, and can fail for more reasons. I think it
would suffice to mention XenIoMmioInstall() and the status it returns.
(XenIoMmioInstall() logs errors internally anyway.) I don't insist though.

 +break;
 +  }
 +
 +  DEBUG ((EFI_D_INFO, Found Xen node with Grant table @ 0x%p\n, 
 RegBase));

(2) 0x%p is incorrect here, please say 0x%Lx. RegBase is not a pointer
but a UINT64.

 +
 +  break;
 +
  default:
break;
  }
 diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf 
 b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf
 index 1392c7c3fa45..f8a58238c37b 100644
 --- a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf
 +++ b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf
 @@ -41,6 +41,7 @@
FdtLib
VirtioMmioDeviceLib
HobLib
 +  XenIoMmioLib
  
  [Guids]
gFdtTableGuid
 

With those changes:

Reviewed-by: Laszlo Ersek ler...@redhat.com

Thanks
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 17/29] Ovmf/Xen: refactor XenBusDxe hypercall implementation

[Laszlo Ersek]

)
  {
 -  ASSERT (Dev-Hyperpage != NULL);
 -  return XenHypercall2 ((UINT8*)Dev-Hyperpage + 
 __HYPERVISOR_event_channel_op * 32,
 +  return XenHypercall2 (__HYPERVISOR_event_channel_op,
  Operation, (INTN) Arguments);
  }

 -EFI_STATUS
 -XenGetSharedInfoPage (
 -  IN OUT XENBUS_DEVICE *Dev
 +INTN
 +EFIAPI
 +XenHypercall2 (
 +  IN INTN HypercallID,
 +  IN OUT INTN Arg1,
 +  IN OUT INTN Arg2
)
  {
 -  xen_add_to_physmap_t Parameter;
 -
 -  ASSERT (Dev-SharedInfo == NULL);
 +  ASSERT (HyperPage != NULL);

 -  Parameter.domid = DOMID_SELF;
 -  Parameter.space = XENMAPSPACE_shared_info;
 -  Parameter.idx = 0;
 -
 -  //
 -  // using reserved page because the page is not released when Linux is
 -  // starting because of the add_to_physmap. QEMU might try to access the
 -  // page, and fail because it have no right to do so (segv).
 -  //
 -  Dev-SharedInfo = AllocateReservedPages (1);
 -  Parameter.gpfn = (UINTN) Dev-SharedInfo  EFI_PAGE_SHIFT;
 -  if (XenHypercallMemoryOp (Dev, XENMEM_add_to_physmap, Parameter) != 0) 
 {
 -FreePages (Dev-SharedInfo, 1);
 -Dev-SharedInfo = NULL;
 -return EFI_LOAD_ERROR;
 -  }
 -
 -  return EFI_SUCCESS;
 +  return __XenHypercall2 ((UINT8*)HyperPage + HypercallID * 32, Arg1, 
 Arg2);
 ^ shouldn't it be Hyperpage?


 Yes, you are quite right. My build test on x86 should have spotted
 this, so apparently I screwed that up in some way as well.

 
 Turns out this was a refactoring error that got cleaned up by the next
 patch, and I did not perform the x86 build test on each patch in
 isolation.
 Will be fixed in v3
 

I skimmed this patch. It makes sense to me as preparation for
librarizing the hypercall machinery (as you say in the commit message),
if the Xen guys don't have any objections.

I peeked forward at patch 18. The librarization is certainly possible
given that the origin of your info is the GUID HOB with gEfiXenInfoGuid.

So, I got curious about the data pointed-to by the gEfiXenInfoGuid
HOB... It's set up in OvmfPkg/PlatformPei/Xen.c. I froze for a second,
but then I noticed it uses BuildGuidDataHob(), *not* BuildGuidHob(); ie.
it *copies* mXenInfo into the HOB. Good.

I think this patch (and the next one) improve OVMF/Xen even in isolation
(== without thinking of ARM at all).

For v3:

Acked-by: Laszlo Ersek ler...@redhat.com

Thanks
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 18/29] Ovmf/Xen: move XenBusDxe hypercall code to separate library

[Laszlo Ersek]

one important comment

On 01/26/15 20:03, Ard Biesheuvel wrote:
 This moves all of the Xen hypercall code that was private to XenBusDxe
 to a new library class XenHypercallLib. This will allow us to reimplement
 it for ARM, and to export the Xen hypercall functionality to other parts
 of the code, such as a Xen console SerialPortLib driver.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  OvmfPkg/{XenBusDxe/XenHypercall.h = Include/Library/XenHypercallLib.h} | 16 
 ++-
  OvmfPkg/{XenBusDxe = Library/XenHypercallLib}/Ia32/hypercall.nasm  |  0
  OvmfPkg/{XenBusDxe = Library/XenHypercallLib}/X64/hypercall.nasm   |  0
  OvmfPkg/{XenBusDxe = Library/XenHypercallLib}/XenHypercall.c   | 37 
 ++
  OvmfPkg/Library/XenHypercallLib/XenHypercallIntel.c | 77 
 +++
  OvmfPkg/Library/XenHypercallLib/XenHypercallLibIntel.inf| 52 
 
  OvmfPkg/OvmfPkg.dec |  4 
 
  OvmfPkg/OvmfPkgIa32.dsc |  1 
 +
  OvmfPkg/OvmfPkgIa32X64.dsc  |  1 
 +
  OvmfPkg/OvmfPkgX64.dsc  |  1 
 +
  OvmfPkg/XenBusDxe/EventChannel.c|  3 
 ++-
  OvmfPkg/XenBusDxe/GrantTable.c  |  2 
 +-
  OvmfPkg/XenBusDxe/XenBusDxe.c   |  9 
 +
  OvmfPkg/XenBusDxe/XenBusDxe.inf | 11 
 +--
  OvmfPkg/XenBusDxe/XenStore.c|  2 
 +-
  15 files changed, 146 insertions(+), 70 deletions(-)
 
 diff --git a/OvmfPkg/XenBusDxe/XenHypercall.h 
 b/OvmfPkg/Include/Library/XenHypercallLib.h
 similarity index 82%
 rename from OvmfPkg/XenBusDxe/XenHypercall.h
 rename to OvmfPkg/Include/Library/XenHypercallLib.h
 index 9d49e33eb5af..dc2c5424683c 100644
 --- a/OvmfPkg/XenBusDxe/XenHypercall.h
 +++ b/OvmfPkg/Include/Library/XenHypercallLib.h
 @@ -13,8 +13,8 @@
  
  **/
  
 -#ifndef __XENBUS_DXE_HYPERCALL_H__
 -#define __XENBUS_DXE_HYPERCALL_H__
 +#ifndef __XEN_HYPERCALL_LIB_H_
 +#define __XEN_HYPERCALL_LIB_H_

I guess if you lead it with __, then you should also trail it with
__. :)

Other than that, it looks good to me.

Reviewed-by: Laszlo Ersek ler...@redhat.com

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 19/29] Ovmf/Xen: introduce XENIO_PROTOCOL

[Laszlo Ersek]

On 01/26/15 20:03, Ard Biesheuvel wrote:
 This introduces the abstract XENIO_PROTOCOL that will be used to
 communicate the Xen grant table address to drivers supporting this
 protocol. Primary purpose is allowing us to change the XenBusDxe
 implementation so that it can support non-PCI Xen implementations
 such as Xen on ARM.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  OvmfPkg/Include/Protocol/XenIo.h | 48 
 
  OvmfPkg/OvmfPkg.dec  |  1 +
  2 files changed, 49 insertions(+)
 
 diff --git a/OvmfPkg/Include/Protocol/XenIo.h 
 b/OvmfPkg/Include/Protocol/XenIo.h
 new file mode 100644
 index ..510391f3b3e8
 --- /dev/null
 +++ b/OvmfPkg/Include/Protocol/XenIo.h
 @@ -0,0 +1,48 @@
 +/** @file
 +  XenIo protocol to abstract arch specific details
 +
 +  The Xen implementations for the Intel and ARM archictures differ in the way
 +  the base address of the grant table is communicated to the guest. The 
 former
 +  uses a virtual PCI device, while the latter uses a device tree node.
 +  In order to allow the XenBusDxe UEFI driver to be reused for the non-PCI
 +  Xen implementation, this abstract protocol can be installed on a handle
 +  with the appropriate base address.
 +
 +  Copyright (C) 2014, Linaro Ltd.
 +
 +  This program and the accompanying materials
 +  are licensed and made available under the terms and conditions of the BSD 
 License
 +  which accompanies this distribution.  The full text of the license may be 
 found at
 +  http://opensource.org/licenses/bsd-license.php
 +
 +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
 +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
 IMPLIED.
 +
 +**/
 +
 +#ifndef __PROTOCOL_XENIO_H__
 +#define __PROTOCOL_XENIO_H__
 +
 +#include IndustryStandard/Xen/xen.h
 +
 +#define XENIO_PROTOCOL_GUID \
 +  {0x6efac84f, 0x0ab0, 0x4747, {0x81, 0xbe, 0x85, 0x55, 0x62, 0x59, 0x04, 
 0x49}}
 +
 +///
 +/// Forward declaration
 +///
 +typedef struct _XENIO_PROTOCOL XENIO_PROTOCOL;
 +
 +///
 +/// Protocol structure
 +///
 +struct _XENIO_PROTOCOL {
 +  //
 +  // Protocol data fields
 +  //
 +  EFI_PHYSICAL_ADDRESS  GrantTableAddress;
 +};
 +
 +extern EFI_GUID gXenIoProtocolGuid;
 +
 +#endif
 diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
 index 30a9fb1e9b42..3711fa922311 100644
 --- a/OvmfPkg/OvmfPkg.dec
 +++ b/OvmfPkg/OvmfPkg.dec
 @@ -58,6 +58,7 @@
gVirtioDeviceProtocolGuid   = {0xfa920010, 0x6785, 0x4941, {0xb6, 
 0xec, 0x49, 0x8c, 0x57, 0x9f, 0x16, 0x0a}}
gBlockMmioProtocolGuid  = {0x6b558ce3, 0x69e5, 0x4c67, {0xa6, 
 0x34, 0xf7, 0xfe, 0x72, 0xad, 0xbe, 0x84}}
gXenBusProtocolGuid = {0x3d3ca290, 0xb9a5, 0x11e3, {0xb7, 
 0x5d, 0xb8, 0xac, 0x6f, 0x7d, 0x65, 0xe6}}
 +  gXenIoProtocolGuid  = {0x6efac84f, 0x0ab0, 0x4747, {0x81, 
 0xbe, 0x85, 0x55, 0x62, 0x59, 0x04, 0x49}}
  
  [PcdsFixedAtBuild]
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|0x0|UINT32|0
 

Reviewed-by: Laszlo Ersek ler...@redhat.com

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 20/29] Ovmf/Xen: add separate driver for Xen PCI device

[Laszlo Ersek]

This code brings back memories :) It even has my earliest edk2 comments
whose vocabulary (in retrospect) is not entirely correct. :) But,
they're not the reason I'll ask for a respin here:

On 01/26/15 20:03, Ard Biesheuvel wrote:
 Prepare for making XenBusDxe suitable for use with non-PCI devices
 (such as the DT node exposed by Xen on ARM) by introducing a separate
 DXE driver that binds to the Xen virtual PCI device and exposes the
 abstract XENIO_PROTOCOL for XenBusDxe to bind against.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  OvmfPkg/XenIoPciDxe/XenIoPciDxe.c   | 365 
 ++
  OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf |  45 +
  2 files changed, 410 insertions(+)
 
 diff --git a/OvmfPkg/XenIoPciDxe/XenIoPciDxe.c 
 b/OvmfPkg/XenIoPciDxe/XenIoPciDxe.c
 new file mode 100644
 index ..8c91590f7eb5
 --- /dev/null
 +++ b/OvmfPkg/XenIoPciDxe/XenIoPciDxe.c
 @@ -0,0 +1,365 @@
 +/** @file
 +
 +  Driver for the virtual Xen PCI device
 +
 +  Copyright (C) 2012, Red Hat, Inc.
 +  Copyright (c) 2012, Intel Corporation. All rights reserved.BR
 +  Copyright (C) 2013, ARM Ltd.
 +  Copyright (C) 2015, Linaro Ltd.
 +
 +  This program and the accompanying materials are licensed and made available
 +  under the terms and conditions of the BSD License which accompanies this
 +  distribution. The full text of the license may be found at
 +  http://opensource.org/licenses/bsd-license.php
 +
 +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS, 
 WITHOUT
 +  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 +
 +**/
 +
 +#include IndustryStandard/Acpi.h
 +#include IndustryStandard/Pci.h
 +#include Library/BaseMemoryLib.h
 +#include Library/DebugLib.h
 +#include Library/MemoryAllocationLib.h
 +#include Library/UefiBootServicesTableLib.h
 +#include Library/UefiLib.h
 +
 +#include Protocol/PciIo.h
 +#include Protocol/XenIo.h
 +
 +#define PCI_VENDOR_ID_XEN0x5853
 +#define PCI_DEVICE_ID_XEN_PLATFORM   0x0001
 +
 +/**
 +
 +  Device probe function for this driver.
 +
 +  The DXE core calls this function for any given device in order to see if 
 the
 +  driver can drive the device.
 +
 +  @param[in]  ThisThe EFI_DRIVER_BINDING_PROTOCOL object
 +  incorporating this driver (independently of
 +  any device).
 +
 +  @param[in] DeviceHandle The device to probe.
 +
 +  @param[in] RemainingDevicePath  Relevant only for bus drivers, ignored.
 +
 +
 +  @retval EFI_SUCCESS  The driver supports the device being probed.
 +
 +  @retval EFI_UNSUPPORTED  The driver does not support the device being 
 probed.
 +
 +  @return  Error codes from the OpenProtocol() boot service 
 or
 +   the PciIo protocol.
 +
 +**/
 +STATIC
 +EFI_STATUS
 +EFIAPI
 +XenIoPciDeviceBindingSupported (
 +  IN EFI_DRIVER_BINDING_PROTOCOL *This,
 +  IN EFI_HANDLE  DeviceHandle,
 +  IN EFI_DEVICE_PATH_PROTOCOL*RemainingDevicePath
 +  )
 +{
 +  EFI_STATUS  Status;
 +  EFI_PCI_IO_PROTOCOL *PciIo;
 +  PCI_TYPE00  Pci;
 +
 +  //
 +  // Attempt to open the device with the PciIo set of interfaces. On success,
 +  // the protocol is instantiated for the PCI device. Covers duplicate open
 +  // attempts (EFI_ALREADY_STARTED).
 +  //
 +  Status = gBS-OpenProtocol (
 +  DeviceHandle,   // candidate device
 +  gEfiPciIoProtocolGuid, // for generic PCI access
 +  (VOID **)PciIo,// handle to instantiate
 +  This-DriverBindingHandle,  // requestor driver identity
 +  DeviceHandle,   // ControllerHandle, according 
 to
 +  // the UEFI Driver Model
 +  EFI_OPEN_PROTOCOL_BY_DRIVER // get exclusive PciIo access 
 to
 +  // the device; to be released
 +  );
 +  if (EFI_ERROR (Status)) {
 +return Status;
 +  }
 +
 +  //
 +  // Read entire PCI configuration header for more extensive check ahead.
 +  //
 +  Status = PciIo-Pci.Read (
 +PciIo,// (protocol, device)
 +  // handle
 +EfiPciIoWidthUint32,  // access width  copy
 +  // mode
 +0,// Offset
 +sizeof Pci / sizeof (UINT32), // Count
 +Pci  // target buffer
 +);
 +
 +  if (Status == EFI_SUCCESS) {
 +if ((Pci.Hdr.VendorId == PCI_VENDOR_ID_XEN) 
 +

Re: [Xen-devel] [PATCH v2 24/29] Ovmf/Xen: add Xen PV console SerialPortLib driver

[Laszlo Ersek]

Unless I'm wrong, please:

On 01/26/15 20:03, Ard Biesheuvel wrote:
 This implements a SerialPortLib instance that wires up to the
 PV console ring used by domU guests. Also imports the required
 upstream Xen io/console.h header.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  OvmfPkg/Include/IndustryStandard/Xen/io/console.h   |  51 
 ++
  OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c   | 147 
 ++
  OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf |  34 
 +
  3 files changed, 232 insertions(+)
 
 diff --git a/OvmfPkg/Include/IndustryStandard/Xen/io/console.h 
 b/OvmfPkg/Include/IndustryStandard/Xen/io/console.h
 new file mode 100644
 index ..f1caa9765bcf
 --- /dev/null
 +++ b/OvmfPkg/Include/IndustryStandard/Xen/io/console.h
 @@ -0,0 +1,51 @@
 +/**
 + * console.h
 + *
 + * Console I/O interface for Xen guest OSes.
 + *
 + * Permission is hereby granted, free of charge, to any person obtaining a 
 copy
 + * of this software and associated documentation files (the Software), to
 + * deal in the Software without restriction, including without limitation the
 + * rights to use, copy, modify, merge, publish, distribute, sublicense, 
 and/or
 + * sell copies of the Software, and to permit persons to whom the Software is
 + * furnished to do so, subject to the following conditions:
 + *
 + * The above copyright notice and this permission notice shall be included in
 + * all copies or substantial portions of the Software.
 + *
 + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 
 THE
 + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
 + * DEALINGS IN THE SOFTWARE.
 + *
 + * Copyright (c) 2005, Keir Fraser
 + */
 +
 +#ifndef __XEN_PUBLIC_IO_CONSOLE_H__
 +#define __XEN_PUBLIC_IO_CONSOLE_H__
 +
 +typedef UINT32 XENCONS_RING_IDX;
 +
 +#define MASK_XENCONS_IDX(idx, ring) ((idx)  (sizeof(ring)-1))
 +
 +struct xencons_interface {
 +char in[1024];
 +char out[2048];
 +XENCONS_RING_IDX in_cons, in_prod;
 +XENCONS_RING_IDX out_cons, out_prod;
 +};
 +
 +#endif /* __XEN_PUBLIC_IO_CONSOLE_H__ */
 +
 +/*
 + * Local variables:
 + * mode: C
 + * c-file-style: BSD
 + * c-basic-offset: 4
 + * tab-width: 4
 + * indent-tabs-mode: nil
 + * End:
 + */
 diff --git 
 a/OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c 
 b/OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c
 new file mode 100644
 index ..97344dc4efb0
 --- /dev/null
 +++ b/OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c
 @@ -0,0 +1,147 @@
 +/** @file
 +  Xen console SerialPortLib instance
 +
 +  Copyright (c) 2015, Linaro Ltd. All rights reserved.BR
 +
 +  This program and the accompanying materials
 +  are licensed and made available under the terms and conditions of the BSD 
 License
 +  which accompanies this distribution.  The full text of the license may be 
 found at
 +  http://opensource.org/licenses/bsd-license.php
 +
 +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
 +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
 IMPLIED.
 +
 +**/
 +
 +#include Base.h
 +#include Uefi/UefiBaseType.h
 +
 +#include Library/BaseLib.h
 +#include Library/SerialPortLib.h
 +#include Library/XenHypercallLib.h
 +
 +#include IndustryStandard/Xen/io/console.h
 +#include IndustryStandard/Xen/hvm/params.h
 +#include IndustryStandard/Xen/event_channel.h
 +
 +STATIC evtchn_send_t  mXenConsoleEventChain;
 +STATIC struct xencons_interface   *mXenConsoleInterface;

add a big fat warning above these variables with static storage
duration. You didn't restrict the UEFI phases in which this library is
usable, hence I'm thinking you'll use it in PEIMs and probably even in
SEC. Writable globals in SEC  PEI depend on those phases running out of
DRAM, not flash, which makes this library specific to PrePi. I think the
variables above merit a comment about this.

No other comments from me for this patch (the R-b from Stefano should
suffice).

Thanks
Laszlo

 +
 +RETURN_STATUS
 +EFIAPI
 +SerialPortInitialize (
 +  VOID
 +  )
 +{
 +  mXenConsoleEventChain.port = (UINT32)XenHypercallHvmGetParam 
 (HVM_PARAM_CONSOLE_EVTCHN);
 +  mXenConsoleInterface = (struct xencons_interface *)(UINTN)
 +(XenHypercallHvmGetParam (HVM_PARAM_CONSOLE_PFN)  EFI_PAGE_SHIFT);
 +
 +  //
 +  // No point in ASSERT'ing here as 

Re: [Xen-devel] [PATCH v2 26/29] Ovfm/Xen: add a Vendor Hardware device path GUID for the XenBus root

[Laszlo Ersek]

On 01/26/15 20:03, Ard Biesheuvel wrote:
 On non-PCI Xen guests (such as ARM), the XenBus root is not a PCI
 device but an abstract 'platform' device. Add a dedicated Vendor
 Hardware device path GUID to identify this node.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  OvmfPkg/Include/Guid/XenBusRootDevice.h | 24 
  OvmfPkg/OvmfPkg.dec |  1 +
  2 files changed, 25 insertions(+)
 
 diff --git a/OvmfPkg/Include/Guid/XenBusRootDevice.h 
 b/OvmfPkg/Include/Guid/XenBusRootDevice.h
 new file mode 100644
 index ..2b6e71018052
 --- /dev/null
 +++ b/OvmfPkg/Include/Guid/XenBusRootDevice.h
 @@ -0,0 +1,24 @@
 +/** @file
 +  GUID to be used to identify the XenBus root node on non-PCI Xen guests
 +
 +  Copyright (C) 2015, Linaro Ltd.
 +
 +  This program and the accompanying materials are licensed and made available
 +  under the terms and conditions of the BSD License that accompanies this
 +  distribution. The full text of the license may be found at
 +  http://opensource.org/licenses/bsd-license.php.
 +
 +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS, 
 WITHOUT
 +  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 +
 +**/
 +
 +#ifndef __XENBUS_ROOT_DEVICE_H__
 +#define __XENBUS_ROOT_DEVICE_H__
 +
 +#define XENBUS_ROOT_DEVICE_GUID \
 +{0xa732241f, 0x383d, 0x4d9c, {0x8a, 0xe1, 0x8e, 0x09, 0x83, 0x75, 0x89, 
 0xd7}}
 +
 +extern EFI_GUID gXenBusRootDeviceGuid;
 +
 +#endif
 diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
 index 3711fa922311..d61600225919 100644
 --- a/OvmfPkg/OvmfPkg.dec
 +++ b/OvmfPkg/OvmfPkg.dec
 @@ -53,6 +53,7 @@
gEfiXenInfoGuid = {0xd3b46f3b, 0xd441, 0x1244, {0x9a, 
 0x12, 0x0, 0x12, 0x27, 0x3f, 0xc1, 0x4d}}
gOvmfPlatformConfigGuid = {0x7235c51c, 0x0c80, 0x4cab, {0x87, 
 0xac, 0x3b, 0x08, 0x4a, 0x63, 0x04, 0xb1}}
gVirtioMmioTransportGuid= {0x837dca9e, 0xe874, 0x4d82, {0xb2, 
 0x9a, 0x23, 0xfe, 0x0e, 0x23, 0xd1, 0xe2}}
 +  gXenBusRootDeviceGuid   = {0xa732241f, 0x383d, 0x4d9c, {0x8a, 
 0xe1, 0x8e, 0x09, 0x83, 0x75, 0x89, 0xd7}}
  
  [Protocols]
gVirtioDeviceProtocolGuid   = {0xfa920010, 0x6785, 0x4941, {0xb6, 
 0xec, 0x49, 0x8c, 0x57, 0x9f, 0x16, 0x0a}}
 

Reviewed-by: Laszlo Ersek ler...@redhat.com

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 05/29] ArmVirtualizationPkg: allow patchable PCD for device tree base address

[Laszlo Ersek]

On 01/26/15 20:03, Ard Biesheuvel wrote:
 To allow a runtime self relocating PrePi instance to discover the base
 address of the device tree at runtime, allow the use of a patchable PCD
 for gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress.
 We will not be using the build time patch tool in this case, but using
 a patchable PCD will make the build system aware that its value is not
 a compile time constant.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec 
| 2 +-
  
 ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
  | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec 
 b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec
 index 99411548aff6..d83117fc6abe 100644
 --- a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec
 +++ b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationPkg.dec
 @@ -34,7 +34,7 @@
gArmVirtualizationTokenSpaceGuid = { 0x0B6F5CA7, 0x4F53, 0x445A, { 0xB7, 
 0x6E, 0x2E, 0x36, 0x5B, 0x80, 0x63, 0x66 } }
gEarlyPL011BaseAddressGuid   = { 0xB199DEA9, 0xFD5C, 0x4A84, { 0x80, 
 0x82, 0x2F, 0x41, 0x70, 0x78, 0x03, 0x05 } }
  
 -[PcdsFixedAtBuild]
 +[PcdsFixedAtBuild, PcdsPatchableInModule]
#
# This is the physical address where the device tree is expected to be 
 stored
# upon first entry into UEFI. This needs to be a FixedAtBuild PCD, so that 
 we
 diff --git 
 a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
  
 b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
 index aa4ced4582e8..3e3074af72f1 100644
 --- 
 a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
 +++ 
 b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
 @@ -96,7 +96,7 @@ ArmPlatformInitializeSystemMemory (
ASSERT (HobData != NULL);
*HobData = 0;
  
 -  DeviceTreeBase = (VOID *)(UINTN)FixedPcdGet64 
 (PcdDeviceTreeInitialBaseAddress);
 +  DeviceTreeBase = (VOID *)(UINTN)PcdGet64 (PcdDeviceTreeInitialBaseAddress);
ASSERT (DeviceTreeBase != NULL);
  
//
 

Reviewed-by: Laszlo Ersek ler...@redhat.com

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 13/29] ArmVirtualizationPkg: allow patchable PCD for FV base address

[Laszlo Ersek]

On 01/26/15 20:03, Ard Biesheuvel wrote:
 Allow the use of a patchable PCD for gArmTokenSpaceGuid.PcdFvBaseAddress
 by moving it from the [FixedPcd] to the [Pcd] section in the INF file of
 PlatformPeiLib.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  
 ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.inf 
 | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)
 
 diff --git 
 a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.inf
  
 b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.inf
 index 96019e4009ff..1fca9b28f9e2 100644
 --- 
 a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.inf
 +++ 
 b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.inf
 @@ -37,9 +37,11 @@
FdtLib
  
  [FixedPcd]
 -  gArmTokenSpaceGuid.PcdFvBaseAddress
gArmTokenSpaceGuid.PcdFvSize
 +
 +[Pcd]
gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress
 +  gArmTokenSpaceGuid.PcdFvBaseAddress
  
  [Guids]
gEarlyPL011BaseAddressGuid
 

It also seems to change the PCD type of PcdDeviceTreeInitialBaseAddress.
Care to mention that too in the commit message, just for completeness?

Reviewed-by: Laszlo Ersek ler...@redhat.com

Thanks
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 16/29] Ovmf/Xen: fix pointer to int cast in XenBusDxe

[Laszlo Ersek]

On 01/26/15 20:03, Ard Biesheuvel wrote:
 On ARM, xen_pfn_t is 64 bits but the size of a pointer is only
 32 bits, so casting between them needs to go via (UINTN). Also
 move the xen_pfn_t cast outside the shift so that we can avoid
 shifting 64-bit quantities on 32-bit architectures, which may
 require runtime library support.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Reviewed-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  OvmfPkg/XenBusDxe/GrantTable.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/OvmfPkg/XenBusDxe/GrantTable.c b/OvmfPkg/XenBusDxe/GrantTable.c
 index 37d3bf786c64..8405edc51bc4 100644
 --- a/OvmfPkg/XenBusDxe/GrantTable.c
 +++ b/OvmfPkg/XenBusDxe/GrantTable.c
 @@ -160,7 +160,7 @@ XenGrantTableInit (
  Parameters.domid = DOMID_SELF;
  Parameters.idx = Index;
  Parameters.space = XENMAPSPACE_grant_table;
 -Parameters.gpfn = (((xen_pfn_t) GrantTable)  EFI_PAGE_SHIFT) + Index;
 +Parameters.gpfn = (xen_pfn_t) ((UINTN) GrantTable  EFI_PAGE_SHIFT) + 
 Index;
  ReturnCode = XenHypercallMemoryOp (Dev, XENMEM_add_to_physmap, 
 Parameters);
  if (ReturnCode != 0) {
DEBUG ((EFI_D_ERROR, Xen GrantTable, add_to_physmap hypercall error: 
 %d\n, ReturnCode));
 @@ -182,7 +182,7 @@ XenGrantTableDeinit (
  
for (Index = NR_GRANT_FRAMES - 1; Index = 0; Index--) {
  Parameters.domid = DOMID_SELF;
 -Parameters.gpfn = (((xen_pfn_t) GrantTable)  EFI_PAGE_SHIFT) + Index;
 +Parameters.gpfn = (xen_pfn_t) ((UINTN) GrantTable  EFI_PAGE_SHIFT) + 
 Index;
  DEBUG ((EFI_D_INFO, Xen GrantTable, removing %X\n, Parameters.gpfn));
  ReturnCode = XenHypercallMemoryOp (Dev, XENMEM_remove_from_physmap, 
 Parameters);
  if (ReturnCode != 0) {
 

One edk2 coding style guideline that I consistently reject  never apply
is the first space in

  (type) expr1 op expr2

We had an obscure bug due to this guideline earlier, which I luckily
managed to catch through review, before it could do damage.

The problem with the first space is that it actively obscures the fact
that the cast operator has one of the strongest operator bindings. Most
of the time, the above means

  ((type)expr1) op expr2

and not

  (type)(expr1 op expr2)

as the space would incorrectly suggest.

Your patch is fine, but I had to think thrice. :)

Reviewed-by: Laszlo Ersek ler...@redhat.com


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 12/29] ArmVirtualizationPkg: implement custom MemoryInitPeiLib

[Laszlo Ersek]

, Linaro Ltd. All rights reserved.BR
 +#  This program and the accompanying materials
 +#  are licensed and made available under the terms and conditions of the BSD 
 License
 +#  which accompanies this distribution.  The full text of the license may be 
 found at
 +#  http://opensource.org/licenses/bsd-license.php
 +#
 +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
 +#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
 IMPLIED.
 +#
 +#**/
 +
 +[Defines]
 +  INF_VERSION= 0x00010005
 +  BASE_NAME  = ArmVirtMemoryInitPeiLib
 +  FILE_GUID  = 021b6156-3cc8-4e99-85ee-13d8a871edf2
 +  MODULE_TYPE= SEC
 +  VERSION_STRING = 1.0
 +  LIBRARY_CLASS  = MemoryInitPeiLib
 +
 +[Sources]
 +  ArmVirtualizationMemoryInitPeiLib.c
 +
 +[Packages]
 +  MdePkg/MdePkg.dec
 +  MdeModulePkg/MdeModulePkg.dec
 +  EmbeddedPkg/EmbeddedPkg.dec
 +  ArmPkg/ArmPkg.dec
 +  ArmPlatformPkg/ArmPlatformPkg.dec
 +
 +[LibraryClasses]
 +  DebugLib
 +  HobLib
 +  ArmLib
 +  ArmPlatformLib
 +
 +[Guids]
 +  gEfiMemoryTypeInformationGuid
 +
 +[FeaturePcd]
 +  gEmbeddedTokenSpaceGuid.PcdPrePiProduceMemoryTypeInformationHob
 +
 +[FixedPcd]
 +  gArmTokenSpaceGuid.PcdFdSize
 +
 +  gArmPlatformTokenSpaceGuid.PcdSystemMemoryUefiRegionSize
 +
 +  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory
 +  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS
 +  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType
 +  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData
 +  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode
 +  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesCode
 +  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesData
 +  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderCode
 +  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderData
 +
 +[Pcd]
 +  gArmTokenSpaceGuid.PcdSystemMemoryBase
 +  gArmTokenSpaceGuid.PcdSystemMemorySize
 +  gArmTokenSpaceGuid.PcdFdBaseAddress
 +
 +[Depex]
 +  TRUE
 

As per the discussion of the previous version of this patch, and because
I can see that ArmVirtualizationMemoryInitPeiLib.inf is only
referenced in patch v2 29/29, where it is added to
ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationXen.dsc:

Acked-by: Laszlo Ersek ler...@redhat.com



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 02/29] ArmPkg: allow patchable PCDs for memory, FD and FV addresses

[Laszlo Ersek]

On 01/26/15 20:03, Ard Biesheuvel wrote:
 In order to allow a runtime self relocating PrePi instance, change the
 allowable PCD types for the following PCDs:
 
   gArmTokenSpaceGuid.PcdSystemMemoryBase
   gArmTokenSpaceGuid.PcdSystemMemorySize
   gArmTokenSpaceGuid.PcdFdBaseAddress
   gArmTokenSpaceGuid.PcdFvBaseAddress
 
 to include PcdsPatchableInModule. This makes the build system correctly
 distinguish fixed PCDs from PCDs whose value may be different from the
 assigned value at compile time.
 
 Note that this only affects platforms that explicitly mark these PCDs as
 PatchableInModule in the DSC. All existing platforms that use FixedPcd
 will not be affected by this change.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  ArmPkg/ArmPkg.dec | 25 ++---
  1 file changed, 14 insertions(+), 11 deletions(-)
 
 diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
 index d7a4826d931a..b01de13e5f78 100644
 --- a/ArmPkg/ArmPkg.dec
 +++ b/ArmPkg/ArmPkg.dec
 @@ -93,14 +93,6 @@
gArmTokenSpaceGuid.PcdSecureFvSize|0x0|UINT32|0x0030
  
#
 -  # ARM Normal (or Non Secure) Firmware PCDs
 -  #
 -  gArmTokenSpaceGuid.PcdFdBaseAddress|0|UINT64|0x002B
 -  gArmTokenSpaceGuid.PcdFdSize|0|UINT32|0x002C
 -  gArmTokenSpaceGuid.PcdFvBaseAddress|0|UINT64|0x002D
 -  gArmTokenSpaceGuid.PcdFvSize|0|UINT32|0x002E
 -
 -  #
# ARM Hypervisor Firmware PCDs
#
gArmTokenSpaceGuid.PcdHypFdBaseAddress|0|UINT32|0x003A
 @@ -127,6 +119,15 @@
# Maximum file size for TFTP servers that do not support 'tsize' extension
gArmTokenSpaceGuid.PcdMaxTftpFileSize|0x0100|UINT32|0x
  
 +  #
 +  # ARM Normal (or Non Secure) Firmware PCDs
 +  #
 +  gArmTokenSpaceGuid.PcdFdSize|0|UINT32|0x002C
 +  gArmTokenSpaceGuid.PcdFvSize|0|UINT32|0x002E
 +
 +[PcdsFixedAtBuild.common, PcdsPatchableInModule.common]
 +  gArmTokenSpaceGuid.PcdFdBaseAddress|0|UINT64|0x002B
 +  gArmTokenSpaceGuid.PcdFvBaseAddress|0|UINT64|0x002D
  
  [PcdsFixedAtBuild.ARM]
#
 @@ -207,16 +208,18 @@
  
  
  #
 -# These PCDs are also defined as 'PcdsDynamic' to be redefined when using 
 UEFI in a
 -# context of virtual machine.
 +# These PCDs are also defined as 'PcdsDynamic' or 'PcdsPatchableInModule' to 
 be
 +# redefined when using UEFI in a context of virtual machine.
  #
 -[PcdsFixedAtBuild.common, PcdsDynamic.common]
 +[PcdsFixedAtBuild.common, PcdsDynamic.common, PcdsPatchableInModule.common]
 +
# System Memory (DRAM): These PCDs define the region of in-built system 
 memory
# Some platforms can get DRAM extensions, these additional regions will be 
 declared
# to UEFI by ArmPlatformLib
gArmTokenSpaceGuid.PcdSystemMemoryBase|0|UINT64|0x0029
gArmTokenSpaceGuid.PcdSystemMemorySize|0|UINT64|0x002A
  
 +[PcdsFixedAtBuild.common, PcdsDynamic.common]
#
# ARM Architectural Timer
#
 

Acked-by: Laszlo Ersek ler...@redhat.com

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1 14/21] Ovmf/Xen: allow non-PCI usage of XenBusDxe

[Laszlo Ersek]

On 01/26/15 14:52, Ard Biesheuvel wrote:

 Well, the problem is that the XenConsoleSerialPortLib implementation
 also needs to issue Xen hypercalls, and needs to do so very early.

In general virtual serial consoles, be they Xen or virtio, are a huge
impedance mismatch (is that the right term?) for UEFI / edk2. For UEFI
/ edk2, the serial port library is one of the lowest level libraries,
because it must be able to give you debug output as early as SEC. Fixed
addresses, minimal state, minimal setup.

However, the virtual serial ports are very stateful and require
elaborate device setup. That matches the DXE phase alright, but nothing
before.

 We
 could still make XENIO_PROTOCOL take its implementations of those
 hypercalls form XenHypercallLib, as XenConsoleSerialPortLib does, but
 I don't think it makes the code more understandable in that case. In
 particular, we would have two different ways of issuing hypercalls
 from code that is Xen-specific, one directly and one through the IO
 protocol.

Agreed. The root cause of that is that the virtual (Xen) serial port is
unsuitable for the original purpose of SerialPortLib -- be super
low-level, available as soon as in SEC, without any kind of discovery,
and just have minimal state. It's a debug device on which everything
else relies on.

(The same is true of virtio-serial, obviously.)

For QEMU ARM guests, we use the emulated (PL011) serial port, which is
easy to program. But you do remember the sad hoops you had jump through
with the DTB because you wanted to make the base address dynamic.

 But I guess the following also makes sense:

 XenBusDxe
/ \
XenIo  ARM vs. Intel hypercall Lib Instance
  |
 PCI vs. DTB

 The second architecture would keep XenIo much thinner, and it's
 certainly sufficient to have only one hypercall method built into the
 entire firmware -- you could decide that question at build time with a
 global library class resolution.

 
 Yes, I think this is the pragmatic choice, and I happen to be feeling
 very pragmatic at the moment :-)

At the moment? :) No doubt. :)

Cheers,
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1 14/21] Ovmf/Xen: allow non-PCI usage of XenBusDxe

[Laszlo Ersek]

On 01/26/15 10:46, Ard Biesheuvel wrote:

 So it would be sufficient to install the XENIO_PROTOCOL on the
 existing ControllerHandle containing the EFI_PCI_IO_PROTOCOL?

Yes.

Because there would be only one PCI (b,d,f) that would qualify (you'd
write up the Supported() check appropriately), there'd be only one
instance of XENIO_PROTOCOL created in the system as well.

 The
 recursion in the UEFI driver model would take care that the
 subordinate bus and devices are discovered as well?

Right. For example, when connecting all drivers to all devices, or when
connecting the device handle coming out of XenIoMmioLib recursively,
or when connecting the PCI (b, d, f) in question recursively, XenBusDxe
would report support for the XENIO protocol instance, then it would be
connected to it, producing a new handle with a XENBUS_PROTOCOL instance
on it for each child. (In fact XENBUS_PROTOCOL should have been called
XEN_DEVICE_PROTOCOL as I understand it, but that's water under the
bridge.) Then the individual device drivers like XenPvBlkDxe would
report support for some of those, etc.

 Well, the point here is that the Xen PCI device is only used as a
 vehicle to convey the grant table address, nothing else. After reading
 the grant table address from BAR1, no other calls into the
 EFI_PCI_IO_PROTOCOL are made at all.

I see. It should still build from the bottom up. In the PCI case, your
chain-reaction is ignited by PCI enumeration, and you should key off
the appropriate PCI (b,d,f) -- see above. In the MMIO case, you do the
DTB-based enumeration yourself, and start it all by calling the library
function on the appropriate register block (or grant table base
address), which then produces a new handle with XENIO_PROTOCOL on it.

It's okay that the hypercall mechanism is orthogonal, but that's an
implementation detail. It should still be hidden behind the
XENIO_PROTOCOL interface in my opinion. You can express the
orthogonality inside the implementation of XENIO_PROTOCOL, by delegating
the hypercalls to a library instance. In theory you could have four
providers of XENIO_PROTOCOL:
- a standalone driver that binds PciIo and uses the Intel hypercall
  style.
- a standalone driver that binds PciIo and uses the ARM hypercall style.
  This difference would be controlled by the library class to library
  instance resolution in the DSC file(s).
- A library that takes the grant table base address as an input
  parameter, and uses the Intel hypercall style.
- A library that takes the grant table base address as an input
  parameter, and uses the ARM hypercall style. (Obviously not
  explicitly, but by delegating hypercalls to whatever library instance
  that the hypercall library class is resolved to.)

Ad absurdum, you could use the library that takes the grant table
address as an input parameter *inside* your PciIo-based driver. Then,
VirtFdtDxe would scan the DTB and call the main library function
directly, whereas your *thin* PciIo-based, standalone driver would
interrogate the PCI device that it recognizes, and delegate the main
work to the library. For this the library would have to be able to take
a device handle from the caller (would be the PCI device handle in the
PCI case, and a fresh handle with just DevicePath on it in the other
case), and install XenIo on that.

If this is feasible or not should become very clear when you get that
far in coding, I think.

 Yes. I agree I need to rework that patch, but the existing
 XenHypercallLib works pretty well, I think.

Absolutely, it makes sense.

 I will proceed and split off XenIoPciDxe from XenBusDxe, which
 installs my existing XENIO_PROTOCOL on the existing ControllerHandle
 if its EFI_PCI_IO_PROTOCOL produces the correct vid/pid and BAR1 mem
 type.

Well... if you don't want to make the hypercall stuff part of the
XENIO_PROTOCOL interface, I can accept that too. My proposal above was:

XenBusDxe
   |
 XenIo
   |
  / \
 /   \
  PCI vs. DTB ARM vs. Intel hypercall Lib Instance

(Ie. XenBusDxe would depend on one abstraction (== XenIo), and XenIo
would depend on two independent abstractions, each of which would have
two possible implementations.)

But I guess the following also makes sense:

XenBusDxe
   / \
   XenIo  ARM vs. Intel hypercall Lib Instance
 |
PCI vs. DTB

The second architecture would keep XenIo much thinner, and it's
certainly sufficient to have only one hypercall method built into the
entire firmware -- you could decide that question at build time with a
global library class resolution.

Please use --stat=150 in the next version, and spoon-feed us the code in
baby bite sized patches! :)

Thanks
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1 14/21] Ovmf/Xen: allow non-PCI usage of XenBusDxe

[Laszlo Ersek]

On 01/23/15 16:03, Ard Biesheuvel wrote:
 While Xen on Intel uses a virtual PCI device to communicate the
 base address of the grant table, the ARM implementation uses a DT
 node, which is fundamentally incompatible with the way XenBusDxe is
 implemented, i.e., as a UEFI Driver Model implementation for a PCI
 device.
 
 To allow the non-PCI implementations to use this driver anyway, this
 patch introduces an abstract XENIO_PROTOCOL protocol, which contains
 just the grant table base address. The Intel implementation is adapted
 to allocate such a protocol on the fly based on the PCI config space
 metadata, so it operates as before. Other users can invoke the driver
 by installing a XENIO_PROTOCOL instance on a handle, and invoking
 ConnectController()
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  OvmfPkg/Include/Protocol/XenIo.h  |  48 ++
  OvmfPkg/OvmfPkg.dec   |   1 +
  OvmfPkg/XenBusDxe/ComponentName.c |   2 +-
  OvmfPkg/XenBusDxe/GrantTable.c|   5 +-
  OvmfPkg/XenBusDxe/GrantTable.h|   3 +-
  OvmfPkg/XenBusDxe/XenBus.c|   6 +-
  OvmfPkg/XenBusDxe/XenBusDxe.c | 190 
 --
  OvmfPkg/XenBusDxe/XenBusDxe.h |   2 +
  OvmfPkg/XenBusDxe/XenBusDxe.inf   |   1 +
  9 files changed, 220 insertions(+), 38 deletions(-)
  create mode 100644 OvmfPkg/Include/Protocol/XenIo.h

This is what we have with virtio:

  EFI_BLOCK_IO_PROTOCOL EFI_SIMPLE_NETWORK_PROTOCOL
  [OvmfPkg/VirtioBlkDxe]  [OvmfPkg/VirtioNetDxe]
 |   |
 | EFI_EXT_SCSI_PASS_THRU_PROTOCOL   |
 | [OvmfPkg/VirtioScsiDxe]   |
 ||  |
 ++--+
  |
   VIRTIO_DEVICE_PROTOCOL
  |
+-+-+
|   |
  [OvmfPkg/VirtioPciDeviceDxe]  [custom platform drivers]
|   |
|   |
   EFI_PCI_IO_PROTOCOL[OvmfPkg/Library/VirtioMmioDeviceLib]
 [MdeModulePkg/Bus/Pci/PciBusDxe]  direct MMIO register access


And this is what we should have for Xen, I think:


 EFI_BLOCK_IO_PROTOCOL
 [OvmfPkg/XenPvBlkDxe]
  |
XENBUS_PROTOCOL
  [OvmfPkg/XenBusDxe]
  |
XENIO_PROTOCOL
  |
+-+---+
| |
 [OvmfPkg/XenIoPciDxe]  
[ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe]
| |
   EFI_PCI_IO_PROTOCOL 
[ArmPlatformPkg/ArmVirtualizationPkg/XenIoMmioLib]
 [MdeModulePkg/Bus/Pci/PciBusDxe]


XENIO_PROTOCOL should abstract both of the following:
- hypercall implementation
- grant table base address

A new driver, OvmfPkg/XenIoPciDxe, would take over the bottom half of
the current OvmfPkg/XenBusDxe driver (discovery, hypercalls etc). It
would install the XENIO_PROTOCOL on the PCI device handle. (Meaning, it
would be a device driver.)

A new library, ArmPlatformPkg/ArmVirtualizationPkg/XenIoMmioLib, would
allow its caller, ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe, to
discover the grant table address in the DTB, and call it with the grant
table base address. The library would then create a new handle, with
instances of the XENIO_PROTOCOL and the EFI_DEVICE_PATH_PROTOCOL on it.
The XENIO_PROTOCOL would again abstract the hypercall implementation as
well.

OvmfPkg/XenBusDxe would preserve only its current top half. All
hypercalls and all PciIo accesses would be rebased to XENIO_PROTOCOL
member calls. Ie. first you have to collect all those accesses and
distill the member functions of XENIO_PROTOCOL first.

This is probably the hardest part of the design. When Olivier did the
same for VIRTIO_DEVICE_PROTOCOL, he was certainly helped by the virtio
specification (and my original, PCI-only source code that carefully
referenced each step in the spec), which had formalized the virtio
operations in human language. This could be a good opportunity to force
the Xen guys to produce a similar document (a text file would suffice).

No changes for XenPvBlkDxe.

If you want, you can still factor out the hypercall implementation to a
separate library. Then use the Intel 

Re: [Xen-devel] [PATCH v1 03/21] ArmVirtualizationPkg: replace instance of FixedPcdGet()

[Laszlo Ersek]

On 01/26/15 11:57, Ard Biesheuvel wrote:
 On 23 January 2015 at 19:38, Laszlo Ersek ler...@redhat.com wrote:
 On 01/23/15 16:02, Ard Biesheuvel wrote:
 This removes an instance of FixedPcdGet () so that the self relocating
 PrePi instance can poke another value into it.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  .../ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c| 
 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git 
 a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
  
 b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
 index aa4ced4582e8..3e3074af72f1 100644
 --- 
 a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
 +++ 
 b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
 @@ -96,7 +96,7 @@ ArmPlatformInitializeSystemMemory (
ASSERT (HobData != NULL);
*HobData = 0;

 -  DeviceTreeBase = (VOID *)(UINTN)FixedPcdGet64 
 (PcdDeviceTreeInitialBaseAddress);
 +  DeviceTreeBase = (VOID *)(UINTN)PcdGet64 
 (PcdDeviceTreeInitialBaseAddress);
ASSERT (DeviceTreeBase != NULL);

//


 Care to include some more rationale in the commit message? From here:

 http://lists.linaro.org/pipermail/linaro-uefi/2014-December/000604.html
 http://lists.linaro.org/pipermail/linaro-uefi/2014-December/000613.html

 You're gearing up to something nasty here, so it bears a bit more
 explanation IMO :)

 Also, after the relocation, FixedPcdGet64() and PcdGet64() would not
 return the same value for the same PCD (despite it being a fixed PCD),
 which is presumably a first in edk2. I can't recommend an alternative,
 but please put a warning comment in the code.

 
 Actually, now that you put it like that, it is quite obvious that
 patchable PCDs are a lot more appropriate here: we wouldn't be using
 the deploy time patch tools, but it would make the build tools report
 inadvertent FixedPcd references to PCDs that cannot be guaranteed to
 retain their build time value.

I did think of patchable-in-module PCDs, but I never used them so I
wasn't sure if your asm relocation trick would work with them.

In any case, if you decide to use them and have to change the PCD type
for a few, please remember to change the referring INF sections too.
(Apparently the right section name is [PatchPcd].)

Thanks
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1 01/21] ArmPkg: allow HYP timer interrupt to be omitted

[Laszlo Ersek]

On 01/23/15 16:02, Ard Biesheuvel wrote:
 The DT binding for the ARM generic timer describes the secure,
 non-secure, virtual and hypervisor timer interrupts, respectively.
 However, under virtualization, only the virtual timer is usable, and
 the device tree may omit the hypervisor timer interrupt. (Other timer
 interrupts cannot be omitted simply due to the fact that the virtual
 timer is listed third)
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  ArmPkg/Drivers/TimerDxe/TimerDxe.c | 14 
 +++---
  .../ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c   |  4 ++--
  2 files changed, 13 insertions(+), 5 deletions(-)
 
 diff --git a/ArmPkg/Drivers/TimerDxe/TimerDxe.c 
 b/ArmPkg/Drivers/TimerDxe/TimerDxe.c
 index d0a819fc2729..1169d426b255 100644
 --- a/ArmPkg/Drivers/TimerDxe/TimerDxe.c
 +++ b/ArmPkg/Drivers/TimerDxe/TimerDxe.c
 @@ -369,7 +369,8 @@ TimerInitialize (
  {
EFI_HANDLE  Handle = NULL;
EFI_STATUS  Status;
 -  UINTN TimerCtrlReg;
 +  UINTN   TimerCtrlReg;
 +  UINT32  TimerHypIntrNum;
  
if (ArmIsArchTimerImplemented () == 0) {
  DEBUG ((EFI_D_ERROR, ARM Architectural Timer is not available in the 
 CPU, hence cann't use this Driver \n));
 @@ -395,8 +396,15 @@ TimerInitialize (
Status = gInterrupt-RegisterInterruptSource (gInterrupt, PcdGet32 
 (PcdArmArchTimerVirtIntrNum), TimerInterruptHandler);
ASSERT_EFI_ERROR (Status);
  
 -  Status = gInterrupt-RegisterInterruptSource (gInterrupt, PcdGet32 
 (PcdArmArchTimerHypIntrNum), TimerInterruptHandler);
 -  ASSERT_EFI_ERROR (Status);
 +  //
 +  // The hypervisor timer interrupt may be omitted by implementations that
 +  // execute under virtualization.
 +  //
 +  TimerHypIntrNum = PcdGet32 (PcdArmArchTimerHypIntrNum);
 +  if (TimerHypIntrNum != 0) {
 +Status = gInterrupt-RegisterInterruptSource (gInterrupt, 
 TimerHypIntrNum, TimerInterruptHandler);
 +ASSERT_EFI_ERROR (Status);
 +  }
  
Status = gInterrupt-RegisterInterruptSource (gInterrupt, PcdGet32 
 (PcdArmArchTimerSecIntrNum), TimerInterruptHandler);
ASSERT_EFI_ERROR (Status);
 diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c 
 b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
 index 751864d4db9c..4e4f608923d3 100644
 --- a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
 +++ b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
 @@ -274,7 +274,7 @@ InitializeVirtFdtDxe (
//  hypervisor timers, in that order.
//
InterruptProp = fdt_getprop (DeviceTreeBase, Node, interrupts, Len);
 -  ASSERT (Len == 48);
 +  ASSERT (Len == 36 || Len == 48);
  
SecIntrNum = fdt32_to_cpu (InterruptProp[0].Number)
 + (InterruptProp[0].Type ? 16 : 0);
 @@ -282,7 +282,7 @@ InitializeVirtFdtDxe (
  + (InterruptProp[1].Type ? 16 : 0);
VirtIntrNum = fdt32_to_cpu (InterruptProp[2].Number)
  + (InterruptProp[2].Type ? 16 : 0);
 -  HypIntrNum = fdt32_to_cpu (InterruptProp[3].Number)
 +  HypIntrNum = Len  48 ? 0 : fdt32_to_cpu (InterruptProp[3].Number)
 + (InterruptProp[3].Type ? 16 : 0);
  
DEBUG ((EFI_D_INFO, Found Timer interrupts %d, %d, %d, %d\n,
 

Please align the plus sign on the second line with the first addend. The
layout should reflect operator binding if possible.

Thanks
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1 03/21] ArmVirtualizationPkg: replace instance of FixedPcdGet()

[Laszlo Ersek]

On 01/23/15 16:02, Ard Biesheuvel wrote:
 This removes an instance of FixedPcdGet () so that the self relocating
 PrePi instance can poke another value into it.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  .../ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c| 2 
 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git 
 a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
  
 b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
 index aa4ced4582e8..3e3074af72f1 100644
 --- 
 a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
 +++ 
 b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
 @@ -96,7 +96,7 @@ ArmPlatformInitializeSystemMemory (
ASSERT (HobData != NULL);
*HobData = 0;
  
 -  DeviceTreeBase = (VOID *)(UINTN)FixedPcdGet64 
 (PcdDeviceTreeInitialBaseAddress);
 +  DeviceTreeBase = (VOID *)(UINTN)PcdGet64 (PcdDeviceTreeInitialBaseAddress);
ASSERT (DeviceTreeBase != NULL);
  
//
 

Care to include some more rationale in the commit message? From here:

http://lists.linaro.org/pipermail/linaro-uefi/2014-December/000604.html
http://lists.linaro.org/pipermail/linaro-uefi/2014-December/000613.html

You're gearing up to something nasty here, so it bears a bit more
explanation IMO :)

Also, after the relocation, FixedPcdGet64() and PcdGet64() would not
return the same value for the same PCD (despite it being a fixed PCD),
which is presumably a first in edk2. I can't recommend an alternative,
but please put a warning comment in the code.

Acked-by: Laszlo Ersek ler...@redhat.com

Thanks
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1 02/21] ArmVirtualizationPkg: add GICv3 detection to VirtFdtDxe

[Laszlo Ersek]

On 01/23/15 16:02, Ard Biesheuvel wrote:
 This adds support for detecting the presence of a GICv3 interrupt
 controller from the device tree, and recording its distributor
 base address in a PCD.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  .../ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c  | 19 
 +++
  1 file changed, 19 insertions(+)
 
 diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c 
 b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
 index 4e4f608923d3..8953f78f5fe4 100644
 --- a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
 +++ b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
 @@ -46,6 +46,7 @@ typedef enum {
PropertyTypeTimer,
PropertyTypePsci,
PropertyTypeFwCfg,
 +  PropertyTypeGicV3,
  } PROPERTY_TYPE;
  
  typedef struct {
 @@ -62,6 +63,7 @@ STATIC CONST PROPERTY CompatibleProperties[] = {
{ PropertyTypeTimer,   arm,armv8-timer },
{ PropertyTypePsci,arm,psci-0.2},
{ PropertyTypeFwCfg,   qemu,fw-cfg-mmio},
 +  { PropertyTypeGicV3,   arm,gic-v3  },
{ PropertyTypeUnknown, }
  };
  
 @@ -256,6 +258,23 @@ InitializeVirtFdtDxe (
DEBUG ((EFI_D_INFO, Found GIC @ 0x%Lx/0x%Lx\n, DistBase, CpuBase));
break;
  
 +case PropertyTypeGicV3:
 +  //
 +  // The GIC v3 DT binding describes a series of at least 3 physical base
 +  // addresses, but we are only interested in the first one, which is the
 +  // distributor interface. (We use the system register CPU interface, 
 not
 +  // the MMIO one)
 +  //
 +  ASSERT (Len = 16);
 +
 +  DistBase = fdt64_to_cpu (((UINT64 *)RegProp)[0]);
 +  ASSERT (DistBase  MAX_UINT32);
 +
 +  PcdSet32 (PcdGicDistributorBase, (UINT32)DistBase);
 +
 +  DEBUG ((EFI_D_INFO, Found GIC v3 distributor @ 0x%Lx\n, DistBase));
 +  break;
 +
  case PropertyTypeRtc:
ASSERT (Len == 16);
  
 

Acked-by: Laszlo Ersek ler...@redhat.com

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1 04/21] ArmVirtualizationPkg: move early UART discovery to PlatformPeim

[Laszlo Ersek]

On 01/23/15 16:02, Ard Biesheuvel wrote:
 This is partially motivated by the desire to use PrePi in a virt
 environment, and in that configuration, ArmPlatformInitializeMemory()
 is never called. But actually, this is a more suitable place anyway.
 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Reviewed-by: Laszlo Ersek ler...@redhat.com
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 ---
  .../Library/ArmVirtualizationPlatformLib/Virt.c| 46 +
  .../Library/PlatformPeiLib/PlatformPeiLib.c| 48 
 ++
  2 files changed, 50 insertions(+), 44 deletions(-)
 
 diff --git 
 a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
  
 b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
 index 3e3074af72f1..17f268697583 100644
 --- 
 a/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
 +++ 
 b/ArmPlatformPkg/ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c
 @@ -24,9 +24,6 @@
  #include Pi/PiBootMode.h
  #include Uefi/UefiBaseType.h
  #include Uefi/UefiMultiPhase.h
 -#include Pi/PiHob.h
 -#include Library/HobLib.h
 -#include Guid/EarlyPL011BaseAddress.h
  
  /**
Return the current Boot Mode
 @@ -77,25 +74,13 @@ ArmPlatformInitializeSystemMemory (
INT32Node, Prev;
UINT64   NewBase;
UINT64   NewSize;
 -  BOOLEAN  HaveMemory, HaveUART;
 -  UINT64   *HobData;
CONST CHAR8  *Type;
 -  CONST CHAR8  *Compatible;
 -  CONST CHAR8  *CompItem;
INT32Len;
CONST UINT64 *RegProp;
 -  UINT64   UartBase;
  
NewBase = 0;
NewSize = 0;
  
 -  HaveMemory = FALSE;
 -  HaveUART   = FALSE;
 -
 -  HobData = BuildGuidHob (gEarlyPL011BaseAddressGuid, sizeof *HobData);
 -  ASSERT (HobData != NULL);
 -  *HobData = 0;
 -
DeviceTreeBase = (VOID *)(UINTN)PcdGet64 (PcdDeviceTreeInitialBaseAddress);
ASSERT (DeviceTreeBase != NULL);
  
 @@ -107,7 +92,7 @@ ArmPlatformInitializeSystemMemory (
//
// Look for a memory node
//
 -  for (Prev = 0; !(HaveMemory  HaveUART); Prev = Node) {
 +  for (Prev = 0;; Prev = Node) {
  Node = fdt_next_node (DeviceTreeBase, Prev, NULL);
  if (Node  0) {
break;
 @@ -140,34 +125,7 @@ ArmPlatformInitializeSystemMemory (
  DEBUG ((EFI_D_ERROR, %a: Failed to parse FDT memory node\n,
 __FUNCTION__));
}
 -  HaveMemory = TRUE;
 -  continue;
 -}
 -
 -//
 -// Check for UART node
 -//
 -Compatible = fdt_getprop (DeviceTreeBase, Node, compatible, Len);
 -
 -//
 -// Iterate over the NULL-separated items in the compatible string
 -//
 -for (CompItem = Compatible; CompItem != NULL  CompItem  Compatible + 
 Len;
 -  CompItem += 1 + AsciiStrLen (CompItem)) {
 -
 -  if (AsciiStrCmp (CompItem, arm,pl011) == 0) {
 -RegProp = fdt_getprop (DeviceTreeBase, Node, reg, Len);
 -ASSERT (Len == 16);
 -
 -UartBase = fdt64_to_cpu (ReadUnaligned64 (RegProp));
 -
 -DEBUG ((EFI_D_INFO, %a: PL011 UART @ 0x%lx\n, __FUNCTION__, 
 UartBase));
 -
 -*HobData = UartBase;
 -
 -HaveUART = TRUE;
 -continue;
 -  }
 +  break;
  }
}
  
 diff --git 
 a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c 
 b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c
 index af0d6e87da9f..58bc2b828dcd 100644
 --- 
 a/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c
 +++ 
 b/ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformPeiLib/PlatformPeiLib.c
 @@ -21,6 +21,8 @@
  #include Library/PcdLib.h
  #include libfdt.h
  
 +#include Guid/EarlyPL011BaseAddress.h
 +
  EFI_STATUS
  EFIAPI
  PlatformPeim (
 @@ -30,6 +32,14 @@ PlatformPeim (
VOID   *Base;
VOID   *NewBase;
UINTN  FdtSize;
 +  UINT64 *UartHobData;
 +  INT32  Node, Prev;
 +  CONST CHAR8*Compatible;
 +  CONST CHAR8*CompItem;
 +  INT32  Len;
 +  CONST UINT64   *RegProp;
 +  UINT64 UartBase;
 +
  
Base = (VOID*)(UINTN)FixedPcdGet64 (PcdDeviceTreeInitialBaseAddress);
ASSERT (fdt_check_header (Base) == 0);
 @@ -41,6 +51,44 @@ PlatformPeim (
CopyMem (NewBase, Base, FdtSize);
PcdSet64 (PcdDeviceTreeBaseAddress, (UINT64)(UINTN)NewBase);
  
 +  UartHobData = BuildGuidHob (gEarlyPL011BaseAddressGuid, sizeof 
 *UartHobData);
 +  ASSERT (UartHobData != NULL);
 +  *UartHobData = 0;
 +
 +  //
 +  // Look for a UART node
 +  //
 +  for (Prev = 0;; Prev = Node) {
 +Node = fdt_next_node (Base, Prev, NULL);
 +if (Node  0) {
 +  break;
 +}
 +
 +//
 +// Check for UART node
 +//
 +Compatible = fdt_getprop (Base, Node, compatible, Len);
 +
 +//
 +// Iterate over the NULL-separated items in the compatible string
 +//
 +for (CompItem = Compatible; CompItem != NULL

Re: [Xen-devel] [PATCH v1 00/21] Xen/ARM guest support

[Laszlo Ersek]

On 01/23/15 16:02, Ard Biesheuvel wrote:

  ArmPkg/Drivers/TimerDxe/TimerDxe.c |  14 +-
  .../ArmVirtualizationPkg/ArmVirtualizationPkg.dec  |   3 +-
  .../ArmVirtualizationPkg/ArmVirtualizationQemu.dsc |   3 -
  .../ArmVirtualizationPkg/ArmVirtualizationXen.dsc  | 274 +
  .../ArmVirtualizationPkg/ArmVirtualizationXen.fdf  | 337 
  .../ArmVirtualizationPkg/Include/Guid/FdtHob.h |  26 ++
  .../ArmVirtualizationMemoryInitPeiLib.c|  91 +
  .../ArmVirtualizationMemoryInitPeiLib.inf  |  64 +++
  .../AARCH64/MemnodeParser.S| 232 +++
  .../AARCH64/RelocatableVirtHelper.S| 161 
  .../ArmVirtualizationPlatformLib.inf   |   1 +
  .../ArmXenRelocatablePlatformLib.inf   |  66 
  .../ArmVirtualizationPlatformLib/RelocatableVirt.c |  78 
  .../Library/ArmVirtualizationPlatformLib/Virt.c|  48 +--
  .../ArmVirtualizationPlatformLib/XenVirtMem.c  |  83 
  .../Library/PlatformPeiLib/PlatformPeiLib.c|  75 +++-
  .../Library/PlatformPeiLib/PlatformPeiLib.inf  |   3 -
  .../ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c   | 129 +-
  .../ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf |   5 +-
  ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S|  51 ++-
  ArmPlatformPkg/PrePi/MainMPCore.c  |   5 +-
  ArmPlatformPkg/PrePi/MainUniCore.c |   2 +-
  ArmPlatformPkg/PrePi/MainUniCoreRelocatable.c  |  38 ++
  ArmPlatformPkg/PrePi/PeiUniCoreRelocatable.inf | 108 +
  ArmPlatformPkg/PrePi/PrePi.c   |  25 +-
  ArmPlatformPkg/PrePi/PrePi.h   |   3 +-
  ArmPlatformPkg/PrePi/Scripts/PrePi-PIE.lds |  28 ++
  OvmfPkg/Include/Guid/XenBusRootDevice.h|  24 ++
  .../Include/IndustryStandard/Xen/arch-arm/xen.h| 436 
 +
  OvmfPkg/Include/IndustryStandard/Xen/io/console.h  |  51 +++
  OvmfPkg/Include/IndustryStandard/Xen/xen.h |   7 +-
  OvmfPkg/Include/Library/XenHypercallLib.h  |  78 
  OvmfPkg/Include/Protocol/XenIo.h   |  48 +++
  .../XenConsoleSerialPortLib.c  | 147 +++
  .../XenConsoleSerialPortLib.inf|  34 ++
  .../Library/XenHypercallLib/Aarch64/Hypercall.S|  26 ++
  OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S|  25 ++
  .../XenHypercallLib}/Ia32/hypercall.nasm   |   6 +-
  .../XenHypercallLib}/X64/hypercall.nasm|   6 +-
  .../Library/XenHypercallLib/XenHypercallLibArm.inf |  40 ++
  .../XenHypercallLib/XenHypercallLibCommon.c|  63 +++
  .../Library/XenHypercallLib/XenHypercallLibIntel.c |  77 
  .../XenHypercallLib/XenHypercallLibIntel.inf   |  52 +++
  .../XenRealTimeClockLib/XenRealTimeClockLib.c  | 196 +
  .../XenRealTimeClockLib/XenRealTimeClockLib.inf|  38 ++
  OvmfPkg/OvmfPkg.dec|   6 +
  OvmfPkg/OvmfPkgIa32.dsc|   1 +
  OvmfPkg/OvmfPkgIa32X64.dsc |   1 +
  OvmfPkg/OvmfPkgX64.dsc |   1 +
  OvmfPkg/XenBusDxe/AtomicsGcc.c |  44 +++
  OvmfPkg/XenBusDxe/ComponentName.c  |   2 +-
  OvmfPkg/XenBusDxe/EventChannel.c   |  14 +-
  OvmfPkg/XenBusDxe/GrantTable.c |  15 +-
  OvmfPkg/XenBusDxe/GrantTable.h |   3 +-
  OvmfPkg/XenBusDxe/XenBus.c |   6 +-
  OvmfPkg/XenBusDxe/XenBusDxe.c  | 241 ++--
  OvmfPkg/XenBusDxe/XenBusDxe.h  |   8 +-
  OvmfPkg/XenBusDxe/XenBusDxe.inf|  15 +-
  OvmfPkg/XenBusDxe/XenHypercall.c   | 118 --
  OvmfPkg/XenBusDxe/XenHypercall.h   | 113 --
  OvmfPkg/XenBusDxe/XenStore.c   |   6 +-
  OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h  |   4 -

Just a very quick skim for now, because you'll probably submit a v2 with
the more fine-grained structure requested by Stefano (which I welcome,
because it'll be easier to review).

First: please don't forget --stat=150 next time :)

Thanks
Laszlo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel