Re: [Xen-devel] [PATCH RFC 00/39] x86/KVM: Xen HVM guest support

[Juergen Gross]

On 08/04/2019 19:31, Joao Martins wrote:
> On 4/8/19 11:42 AM, Juergen Gross wrote:
>> On 08/04/2019 12:36, Joao Martins wrote:
>>> On 4/8/19 7:44 AM, Juergen Gross wrote:
 On 12/03/2019 18:14, Joao Martins wrote:
> On 2/22/19 4:59 PM, Paolo Bonzini wrote:
>> On 21/02/19 12:45, Joao Martins wrote:
>>> On 2/20/19 9:09 PM, Paolo Bonzini wrote:
 On 20/02/19 21:15, Joao Martins wrote:
>  2. PV Driver support (patches 17 - 39)
>
>  We start by redirecting hypercalls from the backend to routines
>  which emulate the behaviour that PV backends expect i.e. grant
>  table and interdomain events. Next, we add support for late
>  initialization of xenbus, followed by implementing
>  frontend/backend communication mechanisms (i.e. grant tables and
>  interdomain event channels). Finally, introduce xen-shim.ko,
>  which will setup a limited Xen environment. This uses the added
>  functionality of Xen specific shared memory (grant tables) and
>  notifications (event channels).

 I am a bit worried by the last patches, they seem really brittle and
 prone to breakage.  I don't know Xen well enough to understand if the
 lack of support for GNTMAP_host_map is fixable, but if not, you have to
 define a completely different hypercall.

>>> I guess Ankur already answered this; so just to stack this on top of 
>>> his comment.
>>>
>>> The xen_shim_domain() is only meant to handle the case where the backend
>>> has/can-have full access to guest memory [i.e. netback and blkback 
>>> would work
>>> with similar assumptions as vhost?]. For the normal case, where a 
>>> backend *in a
>>> guest* maps and unmaps other guest memory, this is not applicable and 
>>> these
>>> changes don't affect that case.
>>>
>>> IOW, the PV backend here sits on the hypervisor, and the hypercalls 
>>> aren't
>>> actual hypercalls but rather invoking shim_hypercall(). The call chain 
>>> would go
>>> more or less like:
>>>
>>> 
>>>  gnttab_map_refs(map_ops, pages)
>>>HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,...)
>>>  shim_hypercall()
>>>shim_hcall_gntmap()
>>>
>>> Our reasoning was that given we are already in KVM, why mapping a page 
>>> if the
>>> user (i.e. the kernel PV backend) is himself? The lack of 
>>> GNTMAP_host_map is how
>>> the shim determines its user doesn't want to map the page. Also, 
>>> there's another
>>> issue where PV backends always need a struct page to reference the 
>>> device
>>> inflight data as Ankur pointed out.
>>
>> Ultimately it's up to the Xen people.  It does make their API uglier,
>> especially the in/out change for the parameter.  If you can at least
>> avoid that, it would alleviate my concerns quite a bit.
>
> In my view, we have two options overall:
>
> 1) Make it explicit, the changes the PV drivers we have to make in
> order to support xen_shim_domain(). This could mean e.g. a) add a callback
> argument to gnttab_map_refs() that is invoked for every page that gets 
> looked up
> successfully, and inside this callback the PV driver may update it's 
> tracking
> page. Here we no longer have this in/out parameter in gnttab_map_refs, 
> and all
> shim_domain specific bits would be a little more abstracted from Xen PV
> backends. See netback example below the scissors mark. Or b) have sort of 
> a
> translate_gref() and put_gref() API that Xen PV drivers use which make it 
> even
> more explicit that there's no grant ops involved. The latter is more 
> invasive.
>
> 2) The second option is to support guest grant mapping/unmapping [*] to 
> allow
> hosting PV backends inside the guest. This would remove the Xen changes 
> in this
> series completely. But it would require another guest being used
> as netback/blkback/xenstored, and less performance than 1) (though, in 
> theory,
> it would be equivalent to what does Xen with grants/events). The only 
> changes in
> Linux Xen code is adding xenstored domain support, but that is useful on 
> its own
> outside the scope of this work.
>
> I think there's value on both; 1) is probably more familiar for KVM users
> perhaps (as it is similar to what vhost does?) while  2) equates to 
> implementing
> Xen disagregation capabilities in KVM.
>
> Thoughts? Xen maintainers what's your take on this?

 What I'd like best would be a new handle (e.g. xenhost_t *) used as an
 abstraction layer for this kind of stuff. It should be passed to the
 backends and those would pass it on to low-level Xen drivers (xenbus,
 event channels, grant table, ...).

>>> So if IIRC backends would use 

[Xen-devel] [qemu-mainline test] 134497: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 134497 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134497/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-pvopsbroken
 build-arm64-xsm  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 133909
 build-arm64   4 host-install(4)broken REGR. vs. 133909
 build-arm64-pvops 4 host-install(4)broken REGR. vs. 133909
 test-amd64-amd64-xl-shadow   12 guest-start  fail REGR. vs. 133909
 test-amd64-amd64-xl-multivcpu 12 guest-start fail REGR. vs. 133909
 test-armhf-armhf-xl-multivcpu 12 guest-start fail REGR. vs. 133909
 test-amd64-amd64-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail 
REGR. vs. 133909

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds20 guest-start/debian.repeat fail REGR. vs. 133909

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133909
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 133909
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 133909
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 133909
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 133909
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 qemuu10546e09e174e0bb185b66a4c397aa845efcd36e
baseline version:
 qemuu082c0543baa6f237704c83a51658bd7f6ae316d5

Last test of basis   133909  2019-03-18 17:20:53 Z   21 days
Failing since133939  2019-03-20 04:22:12 Z   19 days   15 attempts
Testing same since   134497  2019-04-07 08:42:13 Z1 days1 attempts


People who touched revisions under test:
  "Cédric Le Goater" 
  Alberto Garcia 
  Alex Bennée 
  Alistair Francis 
  Andrew Jones 
  Anthony PERARD 
  BALATON Zoltan 
  Bandan Das 
  Benjamin Herrenschmidt 
  Bin Meng 
  Bishara AbuHattoum 
  Brijesh Singh 
  Chih-Min Chao 
  Cleber Rosa 
  

Re: [Xen-devel] [PATCH] x86/IOMMU: abstract Intel-specific adjust_vtd_irq_affinities()

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, April 8, 2019 7:17 PM
> 
> This can't be folded into the resume hook, as that runs before bringin
> back up APs, but the affinity adjustment wants to happen with all CPUs
> back online. Hence a separate hook is needed such that AMD can then
> leverage it as well.
> 
> Signed-off-by: Jan Beulich 
> 

Reviewed-by: Kevin Tian 

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

[Xen-devel] [PATCH v2 0/3] Xen PCI passthrough fixes

[Igor Druzhinin]

Igor Druzhinin (3):
  OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge
aperture
  OvmfPkg/XenSupport: use a correct PCI host bridge aperture for BAR64
  OvmfPkg/XenSupport: turn off address decoding before BAR sizing

 OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 44 ++-
 1 file changed, 37 insertions(+), 7 deletions(-)

-- 
2.7.4


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

[Xen-devel] [PATCH v2 2/3] OvmfPkg/XenSupport: use a correct PCI host bridge aperture for BAR64

[Igor Druzhinin]

In case BAR64 is placed below 4G choose the correct aperture.
This fixes a failed assertion down the code path.

Contributed-under: TianoCore Contribution Agreement 1.1
Acked-by: Anthony PERARD 
Signed-off-by: Igor Druzhinin 
---
 OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c 
b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
index 5ea63f7..f763134 100644
--- a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
+++ b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
@@ -143,7 +143,11 @@ PcatPciRootBridgeParseBars (
   Length = Length | LShiftU64 ((UINT64) UpperValue, 32);
   Length = (~Length) + 1;
 
-  MemAperture = MemAbove4G;
+  if (Base < BASE_4GB) {
+MemAperture = Mem;
+  } else {
+MemAperture = MemAbove4G;
+  }
 }
 
 Limit = Base + Length - 1;
-- 
2.7.4


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

[Xen-devel] [PATCH v2 3/3] OvmfPkg/XenSupport: turn off address decoding before BAR sizing

[Igor Druzhinin]

On Xen, hvmloader firmware leaves address decoding enabled for
enumerated PCI device before jumping into OVMF. OVMF seems to
expect it to be disabled and tries to size PCI BARs in several places
without disabling it which causes BAR64, for example, being
incorrectly placed by QEMU.

Fix it by disabling PCI address decoding explicitly before the
first attempt to size BARs on Xen.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Igor Druzhinin 
---
Changes in v2:
* coding style issues and minor suggestions
---
 OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c 
b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
index f763134..67a37cd 100644
--- a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
+++ b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
@@ -55,6 +55,35 @@ PcatPciRootBridgeBarExisted (
   EnableInterrupts ();
 }
 
+#define PCI_COMMAND_DECODE ((UINT16)(EFI_PCI_COMMAND_IO_SPACE | \
+ EFI_PCI_COMMAND_MEMORY_SPACE))
+STATIC
+VOID
+PcatPciRootBridgeDecoding (
+  IN  UINTN  Address,
+  IN  BOOLEANEnabled,
+  OUT UINT16 *OriginalValue
+  )
+{
+  UINT16 Value;
+
+  //
+  // Preserve the original value
+  //
+  Value = *OriginalValue;
+  *OriginalValue = PciRead16 (Address);
+
+  if (!Enabled) {
+if (*OriginalValue & PCI_COMMAND_DECODE) {
+  PciWrite16 (Address, *OriginalValue & ~PCI_COMMAND_DECODE);
+}
+  } else {
+if (Value & PCI_COMMAND_DECODE) {
+  PciWrite16 (Address, Value);
+}
+  }
+}
+
 STATIC
 VOID
 PcatPciRootBridgeParseBars (
@@ -81,6 +110,12 @@ PcatPciRootBridgeParseBars (
   UINT64Limit;
   PCI_ROOT_BRIDGE_APERTURE  *MemAperture;
 
+  // Disable address decoding for every device before OVMF starts sizing it
+  PcatPciRootBridgeDecoding (
+PCI_LIB_ADDRESS (Bus, Device, Function, PCI_COMMAND_OFFSET),
+FALSE, (UINT16 *)
+  );
+
   for (Offset = BarOffsetBase; Offset < BarOffsetEnd; Offset += sizeof 
(UINT32)) {
 PcatPciRootBridgeBarExisted (
   PCI_LIB_ADDRESS (Bus, Device, Function, Offset),
-- 
2.7.4


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

[Xen-devel] [PATCH v2 1/3] OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge aperture

[Igor Druzhinin]

This aperture doesn't exist in QEMU-XEN and hvmloader places BARs
in arbitrary order disregarding prefetchable bit. This makes
prefetchable and non-prefetchable BARs to follow each other that's
quite likely with PCI passthrough devices. In that case, the existing
code, that tries to work out aperture boundaries by reading hvmloader
BAR placement, will report a bogus prefetchable aperture which overlaps
with the regular one. It will eventually trigger an assertion in
DXE PCI initialization code.

Do the same thing as OVMF on QEMU-KVM and pass a non-existing aperture
there. It's not necessary to pass additional allocation flags as we set
ResourceAssigned flag on the root bridge which means they will be ignored.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Igor Druzhinin 
---
Changes in v2:
* remove usage of prefetchable aperture entirely
* explained rationale for the change in the description
---
 OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 34 ++-
 1 file changed, 12 insertions(+), 22 deletions(-)

diff --git a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c 
b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
index 9204179..5ea63f7 100644
--- a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
+++ b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
@@ -66,9 +66,7 @@ PcatPciRootBridgeParseBars (
   IN UINTN  BarOffsetEnd,
   IN PCI_ROOT_BRIDGE_APERTURE   *Io,
   IN PCI_ROOT_BRIDGE_APERTURE   *Mem,
-  IN PCI_ROOT_BRIDGE_APERTURE   *MemAbove4G,
-  IN PCI_ROOT_BRIDGE_APERTURE   *PMem,
-  IN PCI_ROOT_BRIDGE_APERTURE   *PMemAbove4G
+  IN PCI_ROOT_BRIDGE_APERTURE   *MemAbove4G
 
 )
 {
@@ -129,11 +127,7 @@ PcatPciRootBridgeParseBars (
   //
   Length = ((~Length) + 1) & 0x;
 
-  if ((Value & BIT3) == BIT3) {
-MemAperture = PMem;
-  } else {
-MemAperture = Mem;
-  }
+  MemAperture = Mem;
 } else {
   //
   // 64bit
@@ -149,11 +143,7 @@ PcatPciRootBridgeParseBars (
   Length = Length | LShiftU64 ((UINT64) UpperValue, 32);
   Length = (~Length) + 1;
 
-  if ((Value & BIT3) == BIT3) {
-MemAperture = PMemAbove4G;
-  } else {
-MemAperture = MemAbove4G;
-  }
+  MemAperture = MemAbove4G;
 }
 
 Limit = Base + Length - 1;
@@ -170,6 +160,8 @@ PcatPciRootBridgeParseBars (
   }
 }
 
+STATIC PCI_ROOT_BRIDGE_APERTURE mNonExistAperture = { MAX_UINT64, 0 };
+
 PCI_ROOT_BRIDGE *
 ScanForRootBridges (
   UINTN  *NumberOfRootBridges
@@ -186,7 +178,7 @@ ScanForRootBridges (
   UINT64 Base;
   UINT64 Limit;
   UINT64 Value;
-  PCI_ROOT_BRIDGE_APERTURE Io, Mem, MemAbove4G, PMem, PMemAbove4G, 
*MemAperture;
+  PCI_ROOT_BRIDGE_APERTURE Io, Mem, MemAbove4G, *MemAperture;
   PCI_ROOT_BRIDGE *RootBridges;
   UINTN  BarOffsetEnd;
 
@@ -206,9 +198,7 @@ ScanForRootBridges (
 ZeroMem (, sizeof (Io));
 ZeroMem (, sizeof (Mem));
 ZeroMem (, sizeof (MemAbove4G));
-ZeroMem (, sizeof (PMem));
-ZeroMem (, sizeof (PMemAbove4G));
-Io.Base = Mem.Base = MemAbove4G.Base = PMem.Base = PMemAbove4G.Base = 
MAX_UINT64;
+Io.Base = Mem.Base = MemAbove4G.Base = MAX_UINT64;
 //
 // Scan all the PCI devices on the primary bus of the PCI root bridge
 //
@@ -313,16 +303,17 @@ ScanForRootBridges (
 
   //
   // Get the Prefetchable Memory range that the PPB is decoding
+  // and merge it into Memory range
   //
   Value = Pci.Bridge.PrefetchableMemoryBase & 0x0f;
   Base = ((UINT32) Pci.Bridge.PrefetchableMemoryBase & 0xfff0) << 16;
   Limit = (((UINT32) Pci.Bridge.PrefetchableMemoryLimit & 0xfff0)
<< 16) | 0xf;
-  MemAperture = 
+  MemAperture = 
   if (Value == BIT0) {
 Base |= LShiftU64 (Pci.Bridge.PrefetchableBaseUpper32, 32);
 Limit |= LShiftU64 (Pci.Bridge.PrefetchableLimitUpper32, 32);
-MemAperture = 
+MemAperture = 
   }
   if (Base < Limit) {
 if (MemAperture->Base > Base) {
@@ -373,8 +364,7 @@ ScanForRootBridges (
   OFFSET_OF (PCI_TYPE00, Device.Bar),
   BarOffsetEnd,
   ,
-  , ,
-  , 
+  , 
 );
 
 //
@@ -446,7 +436,7 @@ ScanForRootBridges (
   InitRootBridge (
 Attributes, Attributes, 0,
 (UINT8) PrimaryBus, (UINT8) SubBus,
-, , , , ,
+, , , , ,
 [*NumberOfRootBridges]
   );
   RootBridges[*NumberOfRootBridges].ResourceAssigned = TRUE;
-- 
2.7.4


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

Re: [Xen-devel] [PATCH v4 1/4] x86: stop handling MSR_IA32_BNDCFGS save/restore in implementation code

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, April 5, 2019 7:30 PM
> 
> >>> On 14.03.19 at 14:51,  wrote:
> > Saving and restoring the value of this MSR is currently handled by
> > implementation-specific code despite it being architectural. This patch
> > moves handling of accesses to this MSR from hvm.c into the msr.c, thus
> > allowing the common MSR save/restore code to handle it.
> >
> > NOTE: Because vmx_get/set_guest_bndcfgs() call vmx_vmcs_enter(), the
> >   struct vcpu pointer passed in, and hence the vcpu pointer passed to
> >   guest_rdmsr() cannot be const.
> >
> > Signed-off-by: Paul Durrant 
> > ---
> > Cc: Kevin Tian 
> > Cc: Jan Beulich 
> > Cc: Andrew Cooper 
> > Cc: Wei Liu 
> > Cc: "Roger Pau Monné" 
> > Cc: Jun Nakajima 
> >
> > v4:
> >  - Cosmetic re-arrangements and an additional ASSERT requested by Jan
> >
> > v3:
> >  - Address further comments from Jan
> >  - Dropped Kevin's R-b because of change to vmx.c
> 
> Kevin,
> 
> you may not have noticed the above.
> 

yes indeed. Thanks for remind!

Reviewed-by: Kevin Tian 
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] VT-d: posted interrupts require interrupt remapping

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, April 5, 2019 3:02 PM
> 
> Initially I had just noticed the unnecessary indirection in the call
> from pi_update_irte(). The generic wrapper having an iommu_intremap
> conditional made me look at the setup code though. So first of all
> enforce the necessary dependency.
> 
> Signed-off-by: Jan Beulich 

Acked-by: Kevin Tian 

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

[Xen-devel] [PATCH 2/2] x86/acpi: Improve suspend and resume process for Zhaoxin CPU

[FionaLi-oc]

When executing SYSEXIT or SYSENTRY in Zhaoxin CPU, CPU needs to
save or restore a set of MSRs.

Signed-off-by: FionaLi-oc 
---
 xen/arch/x86/acpi/suspend.c | 6 --
 xen/arch/x86/x86_64/traps.c | 3 ++-
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/acpi/suspend.c b/xen/arch/x86/acpi/suspend.c
index 00e6012..bcff672 100644
--- a/xen/arch/x86/acpi/suspend.c
+++ b/xen/arch/x86/acpi/suspend.c
@@ -28,7 +28,8 @@ void save_rest_processor_state(void)
 rdmsrl(MSR_CSTAR, saved_cstar);
 rdmsrl(MSR_LSTAR, saved_lstar);
 if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
- boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR )
+ boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_SHANGHAI )
 {
 rdmsrl(MSR_IA32_SYSENTER_ESP, saved_sysenter_esp);
 rdmsrl(MSR_IA32_SYSENTER_EIP, saved_sysenter_eip);
@@ -53,7 +54,8 @@ void restore_rest_processor_state(void)
 wrmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);
 
 if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
- boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR )
+ boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_SHANGHAI )
 {
 /* Recover sysenter MSRs */
 wrmsrl(MSR_IA32_SYSENTER_ESP, saved_sysenter_esp);
diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
index bf7870e..30d7012 100644
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -335,7 +335,8 @@ void subarch_percpu_traps_init(void)
 stub_va += offset;
 
 if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
- boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR )
+ boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_SHANGHAI )
 {
 /* SYSENTER entry. */
 wrmsrl(MSR_IA32_SYSENTER_ESP, stack_bottom);
-- 
1.8.3.1


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

[Xen-devel] [PATCH 1/2] acpi/cpufreq: Support CPU frequency driver for Zhaoxin cpu

[FionaLi-oc]

Implementation of Zhaoxin CPU frequency is compatible with Intel.
Zhaoxin CPU also supports EST.

Signed-off-by: FionaLi-oc 
---
 xen/arch/x86/acpi/cpufreq/cpufreq.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/acpi/cpufreq/cpufreq.c 
b/xen/arch/x86/acpi/cpufreq/cpufreq.c
index 844ab85..9d86fa0 100644
--- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
+++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
@@ -60,7 +60,8 @@ static int check_est_cpu(unsigned int cpuid)
 {
 struct cpuinfo_x86 *cpu = _data[cpuid];
 
-if (cpu->x86_vendor != X86_VENDOR_INTEL ||
+if ((cpu->x86_vendor != X86_VENDOR_INTEL &&
+cpu->x86_vendor != X86_VENDOR_SHANGHAI) ||
 !cpu_has(cpu, X86_FEATURE_EIST))
 return 0;
 
@@ -600,7 +601,8 @@ acpi_cpufreq_cpu_init(struct cpufreq_policy *policy)
 
 /* Check for APERF/MPERF support in hardware
  * also check for boost support */
-if (c->x86_vendor == X86_VENDOR_INTEL && c->cpuid_level >= 6)
+if ((c->x86_vendor == X86_VENDOR_INTEL && c->cpuid_level >= 6) ||
+(c->x86_vendor == X86_VENDOR_SHANGHAI))
 on_selected_cpus(cpumask_of(cpu), feature_detect, policy, 1);
 
 /*
@@ -646,7 +648,8 @@ static int __init cpufreq_driver_init(void)
 int ret = 0;
 
 if ((cpufreq_controller == FREQCTL_xen) &&
-(boot_cpu_data.x86_vendor == X86_VENDOR_INTEL))
+((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) ||
+ (boot_cpu_data.x86_vendor == X86_VENDOR_SHANGHAI)))
 ret = cpufreq_register_driver(_cpufreq_driver);
 else if ((cpufreq_controller == FREQCTL_xen) &&
 (boot_cpu_data.x86_vendor == X86_VENDOR_AMD))
@@ -660,9 +663,10 @@ int cpufreq_cpu_init(unsigned int cpuid)
 {
 int ret;
 
-/* Currently we only handle Intel and AMD processor */
+/* Currently we only handle Intel, AMD and ShangHai processor */
 if ( (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ) ||
- (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ) )
+ (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ) ||
+ (boot_cpu_data.x86_vendor == X86_VENDOR_SHANGHAI ) )
 ret = cpufreq_add_cpu(cpuid);
 else
 ret = -EFAULT;
-- 
1.8.3.1


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

Re: [Xen-devel] [PATCH] x86/vmx: Fixup removals from MSR load-lists

[Tian, Kevin]

> From: Igor Druzhinin [mailto:igor.druzhi...@citrix.com]
> Sent: Thursday, April 4, 2019 10:42 PM
> 
> Commit fd32dcfe ("x86/vmx: Don't leak EFER.NXE into guest context")
> introduced a regression on Harpertown and earlier cores (Gen 1 VT-x)
> where as soon as guest EFER becomes equal to Xen EFER
> (almost any 64-bit VM) stale version of EFER is incorrectly
> loaded into a guest causing almost immediate guest failure.
> 
> Signed-off-by: Igor Druzhinin 

Acked-by: Kevin Tian 

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

[Xen-devel] [PATCH 0/2] x86/iommu: support IOMMU for Zhaoxin CPU

[FionaLi-oc]

The patchset supports some features for Zhaoxin CPU whose vendor
ID is 'Shanghai'. Zhaoxin x86 SOC supports I/O virtualization
which is compatible with Intel I/O virtulizaiton.

Indent with four spaces.

Signed-off-by: FionaLi-oc 
---
 xen/include/asm-x86/iommu.h | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/xen/include/asm-x86/iommu.h b/xen/include/asm-x86/iommu.h
index 8dc3924..ec5a009 100644
--- a/xen/include/asm-x86/iommu.h
+++ b/xen/include/asm-x86/iommu.h
@@ -71,10 +71,11 @@ static inline int iommu_hardware_setup(void)
 {
 switch ( boot_cpu_data.x86_vendor )
 {
-case X86_VENDOR_INTEL:
-return intel_vtd_setup();
-case X86_VENDOR_AMD:
-return amd_iov_detect();
+case X86_VENDOR_INTEL:
+case X86_VENDOR_SHANGHAI:
+return intel_vtd_setup();
+case X86_VENDOR_AMD:
+return amd_iov_detect();
 }
 
 return -ENODEV;
-- 
1.8.3.1


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

Re: [Xen-devel] [PATCH RFC 00/39] x86/KVM: Xen HVM guest support

[Stefano Stabellini]

On Mon, 8 Apr 2019, Joao Martins wrote:
> On 4/8/19 11:42 AM, Juergen Gross wrote:
> > On 08/04/2019 12:36, Joao Martins wrote:
> >> On 4/8/19 7:44 AM, Juergen Gross wrote:
> >>> On 12/03/2019 18:14, Joao Martins wrote:
>  On 2/22/19 4:59 PM, Paolo Bonzini wrote:
> > On 21/02/19 12:45, Joao Martins wrote:
> >> On 2/20/19 9:09 PM, Paolo Bonzini wrote:
> >>> On 20/02/19 21:15, Joao Martins wrote:
>   2. PV Driver support (patches 17 - 39)
> 
>   We start by redirecting hypercalls from the backend to routines
>   which emulate the behaviour that PV backends expect i.e. grant
>   table and interdomain events. Next, we add support for late
>   initialization of xenbus, followed by implementing
>   frontend/backend communication mechanisms (i.e. grant tables and
>   interdomain event channels). Finally, introduce xen-shim.ko,
>   which will setup a limited Xen environment. This uses the added
>   functionality of Xen specific shared memory (grant tables) and
>   notifications (event channels).
> >>>
> >>> I am a bit worried by the last patches, they seem really brittle and
> >>> prone to breakage.  I don't know Xen well enough to understand if the
> >>> lack of support for GNTMAP_host_map is fixable, but if not, you have 
> >>> to
> >>> define a completely different hypercall.
> >>>
> >> I guess Ankur already answered this; so just to stack this on top of 
> >> his comment.
> >>
> >> The xen_shim_domain() is only meant to handle the case where the 
> >> backend
> >> has/can-have full access to guest memory [i.e. netback and blkback 
> >> would work
> >> with similar assumptions as vhost?]. For the normal case, where a 
> >> backend *in a
> >> guest* maps and unmaps other guest memory, this is not applicable and 
> >> these
> >> changes don't affect that case.
> >>
> >> IOW, the PV backend here sits on the hypervisor, and the hypercalls 
> >> aren't
> >> actual hypercalls but rather invoking shim_hypercall(). The call chain 
> >> would go
> >> more or less like:
> >>
> >> 
> >>  gnttab_map_refs(map_ops, pages)
> >>HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,...)
> >>  shim_hypercall()
> >>shim_hcall_gntmap()
> >>
> >> Our reasoning was that given we are already in KVM, why mapping a page 
> >> if the
> >> user (i.e. the kernel PV backend) is himself? The lack of 
> >> GNTMAP_host_map is how
> >> the shim determines its user doesn't want to map the page. Also, 
> >> there's another
> >> issue where PV backends always need a struct page to reference the 
> >> device
> >> inflight data as Ankur pointed out.
> >
> > Ultimately it's up to the Xen people.  It does make their API uglier,
> > especially the in/out change for the parameter.  If you can at least
> > avoid that, it would alleviate my concerns quite a bit.
> 
>  In my view, we have two options overall:
> 
>  1) Make it explicit, the changes the PV drivers we have to make in
>  order to support xen_shim_domain(). This could mean e.g. a) add a 
>  callback
>  argument to gnttab_map_refs() that is invoked for every page that gets 
>  looked up
>  successfully, and inside this callback the PV driver may update it's 
>  tracking
>  page. Here we no longer have this in/out parameter in gnttab_map_refs, 
>  and all
>  shim_domain specific bits would be a little more abstracted from Xen PV
>  backends. See netback example below the scissors mark. Or b) have sort 
>  of a
>  translate_gref() and put_gref() API that Xen PV drivers use which make 
>  it even
>  more explicit that there's no grant ops involved. The latter is more 
>  invasive.
> 
>  2) The second option is to support guest grant mapping/unmapping [*] to 
>  allow
>  hosting PV backends inside the guest. This would remove the Xen changes 
>  in this
>  series completely. But it would require another guest being used
>  as netback/blkback/xenstored, and less performance than 1) (though, in 
>  theory,
>  it would be equivalent to what does Xen with grants/events). The only 
>  changes in
>  Linux Xen code is adding xenstored domain support, but that is useful on 
>  its own
>  outside the scope of this work.
> 
>  I think there's value on both; 1) is probably more familiar for KVM users
>  perhaps (as it is similar to what vhost does?) while  2) equates to 
>  implementing
>  Xen disagregation capabilities in KVM.
> 
>  Thoughts? Xen maintainers what's your take on this?
> >>>
> >>> What I'd like best would be a new handle (e.g. xenhost_t *) used as an
> >>> abstraction layer for this kind of stuff. It should be passed to the
> >>> backends and those 

[Xen-devel] [linux-4.19 test] 134461: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 134461 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134461/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 build-arm64  broken
 build-arm64-pvopsbroken
 build-arm64   4 host-install(4)broken REGR. vs. 129313
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 129313
 build-arm64-pvops 4 host-install(4)broken REGR. vs. 129313
 test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 129313
 test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR. 
vs. 129313
 test-amd64-amd64-examine  4 memdisk-try-append   fail REGR. vs. 129313

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux4d552acf337038028f7e2f63a927afb7adf65fc1
baseline version:
 linux84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d

Last test of basis   129313  2018-11-02 05:39:08 Z  157 days
Failing since

[Xen-devel] [xen-unstable-smoke test] 134550: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 134550 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134550/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 133991
 test-amd64-amd64-libvirt18 guest-start/debian.repeat fail REGR. vs. 133991
 build-armhf   6 xen-buildfail REGR. vs. 133991

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  072a96c4901b4cb084375d0a4ae881876c220b16
baseline version:
 xen  cb70a26f78848fe45f593f7ebc9cfaac760a791b

Last test of basis   133991  2019-03-22 15:00:46 Z   17 days
Failing since134068  2019-03-25 12:00:51 Z   14 days   64 attempts
Testing same since   134550  2019-04-08 20:00:37 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Brian Woods 
  Christian Lindig 
  Doug Goldstein 
  George Dunlap 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Lukas Juenger 
  M A Young 
  Norbert Manthey 
  Oleksandr Andrushchenko 
  Paul Durrant 
  Pawel Wieczorkiewicz 
  Petre Pircalabu 
  Razvan Cojocaru 
  Tamas K Lengyel 
  Wei Liu 
  Xiaochen Wang 
  Xin Li 

jobs:
 build-arm64-xsm  broken  
 build-amd64  pass
 build-armhf  fail
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt fail



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary

broken-job build-arm64-xsm broken
broken-step build-arm64-xsm host-install(4)

Not pushing.

(No revision log; it would be 1654 lines long.)

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

[Xen-devel] [xen-4.8-testing test] 134442: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 134442 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134442/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-pvopsbroken
 build-arm64-xsm  broken
 test-armhf-armhf-libvirt broken  in 134207
 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. 
vs. 130965

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt 4 host-install(4) broken in 134207 pass in 134442
 test-xtf-amd64-amd64-3 69 xtf/test-hvm64-xsa-278 fail in 134207 pass in 134442
 test-amd64-i386-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail in 
134207 pass in 134442
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail in 
134207 pass in 134442
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-saverestore.2 fail in 134207 pass 
in 134442
 test-xtf-amd64-amd64-2 69 xtf/test-hvm64-xsa-278 fail in 134338 pass in 134442
 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail pass in 
133662
 test-xtf-amd64-amd64-2   50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 134207
 test-xtf-amd64-amd64-5   69 xtf/test-hvm64-xsa-278 fail pass in 134338
 test-xtf-amd64-amd64-1   69 xtf/test-hvm64-xsa-278 fail pass in 134338

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 build-arm64-xsm   4 host-install(4)   broken baseline untested
 build-arm64-pvops 4 host-install(4)   broken baseline untested
 build-arm64   4 host-install(4)   broken baseline untested
 test-arm64-arm64-xl-xsm 13 migrate-support-check fail in 133662 never pass
 test-arm64-arm64-xl-credit1 13 migrate-support-check fail in 133662 never pass
 test-arm64-arm64-xl 13 migrate-support-check fail in 133662 never pass
 test-arm64-arm64-xl-credit2 13 migrate-support-check fail in 133662 never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail in 133662 never pass
 test-arm64-arm64-xl 14 saverestore-support-check fail in 133662 never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail in 133662 never 
pass
 test-arm64-arm64-xl-credit1 14 saverestore-support-check fail in 133662 never 
pass
 test-arm64-arm64-xl-credit2 14 saverestore-support-check fail in 133662 never 
pass
 test-arm64-arm64-xl-xsm 14 saverestore-support-check fail in 133662 never pass
 test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 134207 like 
130965
 test-xtf-amd64-amd64-5  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 130965
 test-xtf-amd64-amd64-1  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 130965
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 130965
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 130965
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 130965
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 130965
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 130965
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 130965
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 130965
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 130965
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 130965
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 130965
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 

[Xen-devel] [xen-unstable-smoke test] 134522: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 134522 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134522/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 133991
 build-armhf   6 xen-buildfail REGR. vs. 133991

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  19127340a504c030901fc16d8475fc7d8cfdf8a5
baseline version:
 xen  cb70a26f78848fe45f593f7ebc9cfaac760a791b

Last test of basis   133991  2019-03-22 15:00:46 Z   17 days
Failing since134068  2019-03-25 12:00:51 Z   14 days   63 attempts
Testing same since   134522  2019-04-08 12:03:18 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Brian Woods 
  Christian Lindig 
  Doug Goldstein 
  George Dunlap 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Lukas Juenger 
  M A Young 
  Norbert Manthey 
  Paul Durrant 
  Pawel Wieczorkiewicz 
  Petre Pircalabu 
  Razvan Cojocaru 
  Tamas K Lengyel 
  Wei Liu 
  Xiaochen Wang 
  Xin Li 

jobs:
 build-arm64-xsm  broken  
 build-amd64  pass
 build-armhf  fail
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary

broken-job build-arm64-xsm broken
broken-step build-arm64-xsm host-install(4)

Not pushing.

(No revision log; it would be 1614 lines long.)

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

Re: [Xen-devel] [PATCH] x86/hvm: Fix altp2m_op hypercall continuations

[Andrew Cooper]

On 08/04/2019 19:13, Razvan Cojocaru wrote:
> On 4/8/19 8:39 PM, Andrew Cooper wrote:
>> c/s 9383de210 "x86/altp2m: support for setting restrictions for an array of
>> pages" introduced this logic, but do_hvm_op() was already capable of handling
>> -ERESTART correctly.
>>
>> More problematic however is a continuation from compat_altp2m_op().  The arg
>> written back into register state points into the hypercall XLAT area, not at
>> the original parameter passed by the guest.  It may be truncated by the
>> vmentry, but definitely won't be correct on the next invocation.
>>
>> Delete the hypercall_create_continuation() call, and return -ERESTART, which
>> will cause the compat case to start working correctly.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Jan Beulich 
>> CC: Wei Liu 
>> CC: Roger Pau Monné 
>> CC: Razvan Cojocaru 
>> CC: Petre Pircalabu 
>> ---
>>  xen/arch/x86/hvm/hvm.c | 12 ++--
>>  1 file changed, 2 insertions(+), 10 deletions(-)
>>
>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> index e798b49..cc89ee7 100644
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -4729,12 +4729,10 @@ static int do_altp2m_op(
>>  if ( rc > 0 )
>>  {
>>  a.u.set_mem_access_multi.opaque = rc;
>> +rc = -ERESTART;
>>  if ( __copy_field_to_guest(guest_handle_cast(arg, 
>> xen_hvm_altp2m_op_t),
>> , u.set_mem_access_multi.opaque) )
>>  rc = -EFAULT;
>> -else
>> -rc = hypercall_create_continuation(__HYPERVISOR_hvm_op, 
>> "lh",
>> -   HVMOP_altp2m, arg);
>>  }
>>  break;
> Right, that part was taken from the XENMEM_access_op_set_access_multi
> code and plopped in. Didn't follow the call chain all the way through
> and so missed the simpler way of doing this.

do_memory_op() is the other way around.  The compat wrapper is entered
first, and calls into the native path, and any set-up continuations are
then adjusted by hypercall_xlat_continuation() on the way back out.

All of this parameter handling is chronically complicated, and in
serious need of a more simple way to be found.

> The changes certainly look correct. I'll run some tests tomorrow as well.

Thanks,

~Andrew

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

Re: [Xen-devel] [PATCH] x86/hvm: Fix altp2m_op hypercall continuations

[Razvan Cojocaru]

On 4/8/19 8:39 PM, Andrew Cooper wrote:
> c/s 9383de210 "x86/altp2m: support for setting restrictions for an array of
> pages" introduced this logic, but do_hvm_op() was already capable of handling
> -ERESTART correctly.
> 
> More problematic however is a continuation from compat_altp2m_op().  The arg
> written back into register state points into the hypercall XLAT area, not at
> the original parameter passed by the guest.  It may be truncated by the
> vmentry, but definitely won't be correct on the next invocation.
> 
> Delete the hypercall_create_continuation() call, and return -ERESTART, which
> will cause the compat case to start working correctly.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Wei Liu 
> CC: Roger Pau Monné 
> CC: Razvan Cojocaru 
> CC: Petre Pircalabu 
> ---
>  xen/arch/x86/hvm/hvm.c | 12 ++--
>  1 file changed, 2 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index e798b49..cc89ee7 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4729,12 +4729,10 @@ static int do_altp2m_op(
>  if ( rc > 0 )
>  {
>  a.u.set_mem_access_multi.opaque = rc;
> +rc = -ERESTART;
>  if ( __copy_field_to_guest(guest_handle_cast(arg, 
> xen_hvm_altp2m_op_t),
> , u.set_mem_access_multi.opaque) )
>  rc = -EFAULT;
> -else
> -rc = hypercall_create_continuation(__HYPERVISOR_hvm_op, "lh",
> -   HVMOP_altp2m, arg);
>  }
>  break;

Right, that part was taken from the XENMEM_access_op_set_access_multi
code and plopped in. Didn't follow the call chain all the way through
and so missed the simpler way of doing this.

The changes certainly look correct. I'll run some tests tomorrow as well.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH v6 14/27] x86/percpu: Adapt percpu for PIE support

[Thomas Garnier]

On Mon, Apr 8, 2019 at 10:56 AM Christopher Lameter  wrote:
>
> On Mon, 8 Apr 2019, Thomas Garnier wrote:
>
> > > It didn't work originally but I will revisit to see if I missed something.
> >
> > I revisited and couldn't find a way to prevent relocations to the
> > percpu section. Without PIE, you can reference absolute address which
> > was convenient for percpu.
>
> Can you switch PIE off for the percpu section? If not maybe the linker
> needs to have an additional option?

I don't think so or I didn't find any option to do that. Changing the
linker might be a bit too much if we have a software solution which
doesn't impact performance.

>
> Cannot imagine that this is not possible. You neeed to be able to
> reference registers that are in fixed memory locations.
>
>
> > Christopher: Did you have something specific in mind?
>
> I thought that we just leave it as is.

I would like to as well. I will try couple things at the assembly
level instead of the linker and come back to this thread.

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

Re: [Xen-devel] [PATCH v6 14/27] x86/percpu: Adapt percpu for PIE support

[Christopher Lameter]

On Mon, 8 Apr 2019, Thomas Garnier wrote:

> > It didn't work originally but I will revisit to see if I missed something.
>
> I revisited and couldn't find a way to prevent relocations to the
> percpu section. Without PIE, you can reference absolute address which
> was convenient for percpu.

Can you switch PIE off for the percpu section? If not maybe the linker
needs to have an additional option?

Cannot imagine that this is not possible. You neeed to be able to
reference registers that are in fixed memory locations.


> Christopher: Did you have something specific in mind?

I thought that we just leave it as is.

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

[Xen-devel] [qemu-mainline bisection] complete test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm
testid guest-saverestore

Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  e60483f2f8498ae08ae79ca4c6fb03a3317f5e1e
  Bug not present: 9cd97956cfdde85d5887f2ea54ff598f615ee1b1
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/134544/


  commit e60483f2f8498ae08ae79ca4c6fb03a3317f5e1e
  Author: Markus Armbruster 
  Date:   Wed Mar 13 09:43:30 2019 +0100
  
  vl: Fix to create migration object before block backends again
  
  Recent commit cda4aa9a5a0 moved block backend creation before machine
  property evaluation.  This broke qemu-iotests 055.  Turns out we need
  to create the migration object before block backends, so block
  backends can add migration blockers.  Fix by calling
  migration_object_init() earlier, right before configure_blockdev().
  
  Fixes: cda4aa9a5a08777cf13e164c0543bd4888b8adce
  Reported-by: Kevin Wolf 
  Signed-off-by: Markus Armbruster 
  Signed-off-by: Kevin Wolf 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-mainline/test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm.guest-saverestore.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/qemu-mainline/test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm.guest-saverestore
 --summary-out=tmp/134544.bisection-summary --basis-template=133909 
--blessings=real,real-bisect qemu-mainline 
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm guest-saverestore
Searching for failure / basis pass:
 133997 fail [host=godello0] / 133909 [host=pinot0] 133872 [host=chardonnay1] 
133844 [host=pinot1] 133791 [host=italia1] 133750 [host=merlot1] 133703 
[host=elbling1] 133677 [host=elbling0] 133650 [host=merlot0] 133613 
[host=albana1] 133589 [host=godello1] 133576 ok.
Failure / basis pass flights: 133997 / 133576
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 25e2e4e04f13901b3db903b2301bd11381bdf128 
8089c00979a5b089cff592c6b91420e595657167 
16e5b0787687d8904dad2c026107409eb9bfcb95 
5726a8d0f1958af80ad8e514bc2c18d213e739b7 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
d97a39d903fe33c45be83ac6943a2f82a3649a11 
59e9783ddf18e650622e0573cad4f08db65592e4
Basis pass d542b454908f417cf7586038cde7de9d8fa1d3ef 
8089c00979a5b089cff592c6b91420e595657167 
16e5b0787687d8904dad2c026107409eb9bfcb95 
30921fc1e5fcf904f9afddeece1288f5b16ba017 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
1d31f1872b337e4acac5bf6b3c2a45b66e43b494 
f393b82fe5ba3ed9cfe2b306ffa53368e55b75af
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/libvirt.git#d542b454908f417cf7586038cde7de9d8fa1d3ef-25e2e4e04f13901b3db903b2301bd11381bdf128
 
https://git.savannah.gnu.org/git/gnulib.git/#8089c00979a5b089cff592c6b91420e595657167-8089c00979a5b089cff592c6b91420e595657167
 
https://gitlab.com/keycodemap/keycodemapdb.git#16e5b0787687d8904dad2c026107409eb9bfcb95-16e5b0787687d8904dad2c026107409eb9bfcb95
 git://xenbits.xen.org/linux-pvops.git#30921fc1e5fcf904f9afddeece1288f5b16b\
 a017-5726a8d0f1958af80ad8e514bc2c18d213e739b7 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798
 
git://git.qemu.org/qemu.git#1d31f1872b337e4acac5bf6b3c2a45b66e43b494-d97a39d903fe33c45be83ac6943a2f82a3649a11
 
git://xenbits.xen.org/xen.git#f393b82fe5ba3ed9cfe2b306ffa53368e55b75af-59e9783ddf18e\
 650622e0573cad4f08db65592e4
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
error: The last gc run reported the following. 

[Xen-devel] [PATCH] x86/hvm: Fix altp2m_op hypercall continuations

[Andrew Cooper]

c/s 9383de210 "x86/altp2m: support for setting restrictions for an array of
pages" introduced this logic, but do_hvm_op() was already capable of handling
-ERESTART correctly.

More problematic however is a continuation from compat_altp2m_op().  The arg
written back into register state points into the hypercall XLAT area, not at
the original parameter passed by the guest.  It may be truncated by the
vmentry, but definitely won't be correct on the next invocation.

Delete the hypercall_create_continuation() call, and return -ERESTART, which
will cause the compat case to start working correctly.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Razvan Cojocaru 
CC: Petre Pircalabu 
---
 xen/arch/x86/hvm/hvm.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index e798b49..cc89ee7 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4729,12 +4729,10 @@ static int do_altp2m_op(
 if ( rc > 0 )
 {
 a.u.set_mem_access_multi.opaque = rc;
+rc = -ERESTART;
 if ( __copy_field_to_guest(guest_handle_cast(arg, 
xen_hvm_altp2m_op_t),
, u.set_mem_access_multi.opaque) )
 rc = -EFAULT;
-else
-rc = hypercall_create_continuation(__HYPERVISOR_hvm_op, "lh",
-   HVMOP_altp2m, arg);
 }
 break;
 
@@ -4853,14 +4851,8 @@ static int compat_altp2m_op(
 switch ( a.cmd )
 {
 case HVMOP_altp2m_set_mem_access_multi:
-/*
- * The return code can be positive only if it is the return value
- * of hypercall_create_continuation. In this case, the opaque value
- * must be copied back to the guest.
- */
-if ( rc > 0 )
+if ( rc == -ERESTART )
 {
-ASSERT(rc == __HYPERVISOR_hvm_op);
 a.u.set_mem_access_multi.opaque =
 nat.altp2m_op->u.set_mem_access_multi.opaque;
 if ( __copy_field_to_guest(guest_handle_cast(arg,
-- 
2.1.4


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

Re: [Xen-devel] [PATCH RFC 00/39] x86/KVM: Xen HVM guest support

[Joao Martins]

On 4/8/19 11:42 AM, Juergen Gross wrote:
> On 08/04/2019 12:36, Joao Martins wrote:
>> On 4/8/19 7:44 AM, Juergen Gross wrote:
>>> On 12/03/2019 18:14, Joao Martins wrote:
 On 2/22/19 4:59 PM, Paolo Bonzini wrote:
> On 21/02/19 12:45, Joao Martins wrote:
>> On 2/20/19 9:09 PM, Paolo Bonzini wrote:
>>> On 20/02/19 21:15, Joao Martins wrote:
  2. PV Driver support (patches 17 - 39)

  We start by redirecting hypercalls from the backend to routines
  which emulate the behaviour that PV backends expect i.e. grant
  table and interdomain events. Next, we add support for late
  initialization of xenbus, followed by implementing
  frontend/backend communication mechanisms (i.e. grant tables and
  interdomain event channels). Finally, introduce xen-shim.ko,
  which will setup a limited Xen environment. This uses the added
  functionality of Xen specific shared memory (grant tables) and
  notifications (event channels).
>>>
>>> I am a bit worried by the last patches, they seem really brittle and
>>> prone to breakage.  I don't know Xen well enough to understand if the
>>> lack of support for GNTMAP_host_map is fixable, but if not, you have to
>>> define a completely different hypercall.
>>>
>> I guess Ankur already answered this; so just to stack this on top of his 
>> comment.
>>
>> The xen_shim_domain() is only meant to handle the case where the backend
>> has/can-have full access to guest memory [i.e. netback and blkback would 
>> work
>> with similar assumptions as vhost?]. For the normal case, where a 
>> backend *in a
>> guest* maps and unmaps other guest memory, this is not applicable and 
>> these
>> changes don't affect that case.
>>
>> IOW, the PV backend here sits on the hypervisor, and the hypercalls 
>> aren't
>> actual hypercalls but rather invoking shim_hypercall(). The call chain 
>> would go
>> more or less like:
>>
>> 
>>  gnttab_map_refs(map_ops, pages)
>>HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,...)
>>  shim_hypercall()
>>shim_hcall_gntmap()
>>
>> Our reasoning was that given we are already in KVM, why mapping a page 
>> if the
>> user (i.e. the kernel PV backend) is himself? The lack of 
>> GNTMAP_host_map is how
>> the shim determines its user doesn't want to map the page. Also, there's 
>> another
>> issue where PV backends always need a struct page to reference the device
>> inflight data as Ankur pointed out.
>
> Ultimately it's up to the Xen people.  It does make their API uglier,
> especially the in/out change for the parameter.  If you can at least
> avoid that, it would alleviate my concerns quite a bit.

 In my view, we have two options overall:

 1) Make it explicit, the changes the PV drivers we have to make in
 order to support xen_shim_domain(). This could mean e.g. a) add a callback
 argument to gnttab_map_refs() that is invoked for every page that gets 
 looked up
 successfully, and inside this callback the PV driver may update it's 
 tracking
 page. Here we no longer have this in/out parameter in gnttab_map_refs, and 
 all
 shim_domain specific bits would be a little more abstracted from Xen PV
 backends. See netback example below the scissors mark. Or b) have sort of a
 translate_gref() and put_gref() API that Xen PV drivers use which make it 
 even
 more explicit that there's no grant ops involved. The latter is more 
 invasive.

 2) The second option is to support guest grant mapping/unmapping [*] to 
 allow
 hosting PV backends inside the guest. This would remove the Xen changes in 
 this
 series completely. But it would require another guest being used
 as netback/blkback/xenstored, and less performance than 1) (though, in 
 theory,
 it would be equivalent to what does Xen with grants/events). The only 
 changes in
 Linux Xen code is adding xenstored domain support, but that is useful on 
 its own
 outside the scope of this work.

 I think there's value on both; 1) is probably more familiar for KVM users
 perhaps (as it is similar to what vhost does?) while  2) equates to 
 implementing
 Xen disagregation capabilities in KVM.

 Thoughts? Xen maintainers what's your take on this?
>>>
>>> What I'd like best would be a new handle (e.g. xenhost_t *) used as an
>>> abstraction layer for this kind of stuff. It should be passed to the
>>> backends and those would pass it on to low-level Xen drivers (xenbus,
>>> event channels, grant table, ...).
>>>
>> So if IIRC backends would use the xenhost layer to access grants or frames
>> referenced by grants, and that would grok into some of this. IOW, you would 
>> have
>> two implementors of xenhost: 

Re: [Xen-devel] [PATCH] common/gnttab: Process softirqs while dumping grant tables

[Julien Grall]

Hi,

On 4/5/19 5:38 PM, Andrew Cooper wrote:

On 05/04/2019 17:35, Julien Grall wrote:

On 05/04/2019 17:33, Andrew Cooper wrote:
OSSTest log usually disappear after a few days. Who it be possible to 
copy the relevant part of the log instead?


Can do.  Something like: > (XEN) gnttab_usage_print_all [ key 'g' pressed
Apr  4 20:51:42.779992 (XEN)    active     
shared 
Apr  4 20:51:42.780081 (XEN) [ref] localdom mfn  pin  localdom gmfn 
flags
Apr  4 20:51:42.791855 (XEN) grant-table for remote d0 (v1)
Apr  4 20:51:42.791915 (XEN)   1 frames (64 max), 11 maptrack frames (1024 max)
Apr  4 20:51:42.803911 (XEN) no active grant table entries
Apr  4 20:51:42.803975 (XEN)    active     
shared 
Apr  4 20:51:42.804034 (XEN) [ref] localdom mfn  pin  localdom gmfn 
flags
Apr  4 20:51:42.815923 (XEN) grant-table for remote d1 (v1)
Apr  4 20:51:42.816040 (XEN)   7 frames (32 max), 0 maptrack frames (1024 max)
Apr  4 20:51:42.827834 (XEN) [0x000]  0 0x27e306 0x0002  0 
0x0fefff 0x19
Apr  4 20:51:42.827877 (XEN) [0x009]  0 0x22d9a1 0x0001  0 
0x02f3a1 0x19
Apr  4 20:51:42.827905 (XEN) [0x00a]  0 0x22d99f 0x0001  0 
0x02f39f 0x19

Apr  4 20:51:49.814701 (XEN) [0x8af]  0 0x232f4f 0x0001  0 
0x029d4f 0x19
Apr  4 20:51:49.826827 (XEN) [0x8b0]  0 0x232f4e 0x0001  0 
0x029(XEN) Watchdog timer detects that CPU0 is stuck!
Apr  4 20:51:49.826903 (XEN) [ Xen-4.13-unstable  x86_64  debug=y   Not 
tainted ]



This would work for me.

Cheers,

--
Julien Grall

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

[Xen-devel] [PATCH] xen/cpu: Fix ARM build following c/s 597fbb8

[Andrew Cooper]

c/s 597fbb8 "xen/timers: Fix memory leak with cpu unplug/plug" broke the ARM
build by being the first patch to add park_offline_cpus to common code.

While it is currently specific to Intel hardware (for reasons of being able to
handle machine check exceptions without an immediate system reset), it isn't
inherently architecture specific, so define it to be false on ARM for now.

Add a comment in both smp.h headers explaining the intended behaviour of the
option.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Julien Grall 

This time build tested on ARM.  Sorry!
---
 xen/include/asm-arm/smp.h | 6 ++
 xen/include/asm-x86/smp.h | 4 
 2 files changed, 10 insertions(+)

diff --git a/xen/include/asm-arm/smp.h b/xen/include/asm-arm/smp.h
index 3c12268..fdbcefa 100644
--- a/xen/include/asm-arm/smp.h
+++ b/xen/include/asm-arm/smp.h
@@ -14,6 +14,12 @@ DECLARE_PER_CPU(cpumask_var_t, cpu_core_mask);
 
 #define raw_smp_processor_id() (get_processor_id())
 
+/*
+ * Do we, for platform reasons, need to actually keep CPUs online when we
+ * would otherwise prefer them to be off?
+ */
+#define park_offline_cpus false
+
 extern void noreturn stop_cpu(void);
 
 extern int arch_smp_init(void);
diff --git a/xen/include/asm-x86/smp.h b/xen/include/asm-x86/smp.h
index 09c5545..9f533f9 100644
--- a/xen/include/asm-x86/smp.h
+++ b/xen/include/asm-x86/smp.h
@@ -26,6 +26,10 @@ DECLARE_PER_CPU(cpumask_var_t, cpu_sibling_mask);
 DECLARE_PER_CPU(cpumask_var_t, cpu_core_mask);
 DECLARE_PER_CPU(cpumask_var_t, scratch_cpumask);
 
+/*
+ * Do we, for platform reasons, need to actually keep CPUs online when we
+ * would otherwise prefer them to be off?
+ */
 extern bool park_offline_cpus;
 
 void smp_send_nmi_allbutself(void);
-- 
2.1.4


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

[Xen-devel] [PATCH v2] x86/smt: Support for enabling/disabling SMT at runtime

[Andrew Cooper]

Currently, a user can in combine the output of `xl info -n`, the APCI tables,
and some manual CPUID data to figure out which CPU numbers to feed into
`xen-hptool cpu-offline` to effectively disable SMT at runtime.

A more convenient option is to teach Xen how to perform this action.

Extend XEN_SYSCTL_cpu_hotplug with two new operations.  Introduce a new
smt_up_down_helper() which wrap the cpu_{up,down}_helper() helpers with logic
which understands siblings based on their APIC_ID.

Add libxc stubs, and extend xen-hptool with smt-{enable,disable} options.
These are intended to be shorthands for a loop over cpu-{online,offline}.  It
is intended for use in production scenarios where debugging options such as
`maxcpus=` or other manual plug/unplug configuration has not been used.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 

v2:
 * Fold smt_{up,down}_helper() into smt_up_down_helper()
 * Fix calculation of sibling_mask
 * More clearly document the behaviour and expected restrictions.

While testing this, I've found a further bug.  This is preexisting and can be
provoked on staging, although it is easier to provoke with this patch.

(XEN) Assertion 'entry->prev->next == entry' failed at 
/local/xen.git/xen/include/xen/list.h:184
(XEN) [ Xen-4.13-unstable  x86_64  debug=y   Not tainted ]
(XEN) CPU:0
(XEN) RIP:e008:[] migrate_timer+0x1df/0x2da
(XEN) RFLAGS: 00010087   CONTEXT: hypervisor
(XEN) rax: 830837088038   rbx: 830575928890   rcx: 83084d69e320
(XEN) rdx: 830575928898   rsi: 82d08094002f   rdi: 830575928890
(XEN) rbp: 8300abc27d28   rsp: 8300abc27cc8   r8:  
(XEN) r9:  830575928780   r10: 830575928010   r11: 
(XEN) r12:    r13:    r14: 82d080962080
(XEN) r15: 82d080962080   cr0: 8005003b   cr4: 001526e0
(XEN) cr3: abc17000   cr2: 880072a9f8c0
(XEN) fsb:    gsb: 88007ce0   gss: 
(XEN) ds:    es:    fs:    gs:    ss: e010   cs: e008
(XEN) Xen code around  (migrate_timer+0x1df/0x2da):
(XEN)  8b 4b 10 48 3b 11 74 02 <0f> 0b 48 89 48 08 48 89 01 48 b8 00 01 10 00 01
(XEN) Xen stack trace from rsp=8300abc27cc8:

(XEN) Xen call trace:
(XEN)[] migrate_timer+0x1df/0x2da
(XEN)[] do_IRQ+0x4fc/0x64e
(XEN)[] common_interrupt+0x10a/0x120
(XEN)[] mwait-idle.c#mwait_idle+0x31d/0x370
(XEN)[] domain.c#idle_loop+0xa8/0xc3
(XEN)
(XEN)
(XEN) 
(XEN) Panic on CPU 0:
(XEN) Assertion 'entry->prev->next == entry' failed at 
/local/xen.git/xen/include/xen/list.h:184
(XEN) 
---
 tools/libxc/include/xenctrl.h |  2 ++
 tools/libxc/xc_cpu_hotplug.c  | 26 
 tools/misc/xen-hptool.c   | 56 ++
 xen/arch/x86/sysctl.c | 57 ++-
 xen/include/public/sysctl.h   | 19 +++
 5 files changed, 159 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index a3628e5..49a6b2a 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1854,6 +1854,8 @@ int xc_pm_reset_cxstat(xc_interface *xch, int cpuid);
 
 int xc_cpu_online(xc_interface *xch, int cpu);
 int xc_cpu_offline(xc_interface *xch, int cpu);
+int xc_smt_enable(xc_interface *xch);
+int xc_smt_disable(xc_interface *xch);
 
 /* 
  * cpufreq para name of this structure named 
diff --git a/tools/libxc/xc_cpu_hotplug.c b/tools/libxc/xc_cpu_hotplug.c
index 58c2a0f..2ea9825 100644
--- a/tools/libxc/xc_cpu_hotplug.c
+++ b/tools/libxc/xc_cpu_hotplug.c
@@ -46,3 +46,29 @@ int xc_cpu_offline(xc_interface *xch, int cpu)
 return ret;
 }
 
+int xc_smt_enable(xc_interface *xch)
+{
+DECLARE_SYSCTL;
+int ret;
+
+sysctl.cmd = XEN_SYSCTL_cpu_hotplug;
+sysctl.u.cpu_hotplug.cpu = 0;
+sysctl.u.cpu_hotplug.op = XEN_SYSCTL_CPU_HOTPLUG_SMT_ENABLE;
+ret = xc_sysctl(xch, );
+
+return ret;
+}
+
+int xc_smt_disable(xc_interface *xch)
+{
+DECLARE_SYSCTL;
+int ret;
+
+sysctl.cmd = XEN_SYSCTL_cpu_hotplug;
+sysctl.u.cpu_hotplug.cpu = 0;
+sysctl.u.cpu_hotplug.op = XEN_SYSCTL_CPU_HOTPLUG_SMT_DISABLE;
+ret = xc_sysctl(xch, );
+
+return ret;
+}
+
diff --git a/tools/misc/xen-hptool.c b/tools/misc/xen-hptool.c
index 40cd966..6e27d9c 100644
--- a/tools/misc/xen-hptool.c
+++ b/tools/misc/xen-hptool.c
@@ -19,6 +19,8 @@ void show_help(void)
 "  mem-online  online MEMORY \n"
 "  mem-offline offline MEMORY \n"
 "  mem-status  query Memory status\n"
+"  smt-enable   onlines all SMT threads\n"
+"  smt-disable  offlines all SMT threads\n"
);
 }
 
@@ -304,6 +306,58 @@ static int hp_cpu_offline_func(int argc, char 

[Xen-devel] [xen-unstable test] 134486: trouble: blocked/broken/fail/pass

[osstest service owner]

flight 134486 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134486/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvopsbroken
 build-arm64  broken
 build-arm64-xsm  broken
 build-arm64   4 host-install(4)broken REGR. vs. 134007
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 134007
 build-arm64-pvops 4 host-install(4)broken REGR. vs. 134007

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 134373
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 134373
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 134373
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 134373
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 134373
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 134373
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 134373
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 134373
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 134373
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  cb70a26f78848fe45f593f7ebc9cfaac760a791b
baseline version:
 xen  cb70a26f78848fe45f593f7ebc9cfaac760a791b

Last test of basis   134486  2019-04-06 22:04:13 Z1 days
Testing same since  (not found) 0 attempts

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-i386-xsm   

Re: [Xen-devel] [PATCH v2 0/3] mwait support for AMD processors

[Woods, Brian]

On 3/28/19 10:04 AM, Woods, Brian wrote:
> This patch series add support and enablement for mwait on AMD Naples
> and Rome processors.  Newer AMD processors support mwait, but only for
> c1, and for c2 halt is used.  The mwait-idle driver is modified to be
> able to use both mwait and halt for idling.
> 
> Brian Woods (3):
>mwait-idle: add support for using halt
>mwait-idle: add support for AMD processors
>mwait-idle: add enablement for AMD Naples and Rome
> 
>   xen/arch/x86/acpi/cpu_idle.c  |  2 +-
>   xen/arch/x86/cpu/mwait-idle.c | 62 
> ++-
>   xen/include/asm-x86/cpuidle.h |  1 +
>   3 files changed, 57 insertions(+), 8 deletions(-)
> 

Just a ping to hopefully start the discussion that mentioned in the 
community call.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 3/3] memory: restrict XENMEM_remove_from_physmap to translated guests

[Julien Grall]

Hi Jan,

On 4/8/19 3:02 PM, Jan Beulich wrote:

On 08.04.19 at 13:58,  wrote:

On 3/5/19 1:28 PM, Jan Beulich wrote:

@@ -298,7 +298,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_add_to_physm
   
   /*

* Unmaps the page appearing at a particular GPFN from the specified guest's
- * pseudophysical address space.
+ * physical address space (translated guests only).


While you modify the comment, can you replace GPFN with GFN?


I did consider this when writing the patch, but then this would
bring it out of sync with the structure field and its associated
comment. Plus the "add" side comment would then want
changing too. And public/memory.h has quite a few more uses
of GPFN / gpfn.

To be honest I'd prefer to leave this as is right here, for it to get
cleaned up in one go.


I am fine with that.




Other than that:

Reviewed-by: Julien Grall 


Thanks, but as per above I'm not sure whether to actually apply > it.


Yes it applies, for the common code (and indirectly Arm).

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v6 14/27] x86/percpu: Adapt percpu for PIE support

[Thomas Garnier]

On Fri, Feb 1, 2019 at 9:13 AM Thomas Garnier  wrote:
>
> On Thu, Jan 31, 2019 at 6:31 PM Christopher Lameter  wrote:
> >
> > On Thu, 31 Jan 2019, Thomas Garnier wrote:
> >
> > > The per-cpu symbols are in a section that is zero based to create
> > > offsets. The compiler doesn't see them as offsets but as relative
> > > symbol and try to relocate them. Given the distance between zero and
> > > the mapped kernel is much larger than the instruction offset range, it
> > > fails to do it.
> >
> > We switch that off in the linker. If that does not work with your
> > modifications then you need to figure out how to update the link
> > configuration.
> >
>
> It didn't work originally but I will revisit to see if I missed something.

I revisited and couldn't find a way to prevent relocations to the
percpu section. Without PIE, you can reference absolute address which
was convenient for percpu.

Christopher: Did you have something specific in mind?

I checked the following:
 - Changing the FLAGS() on the PHDRS.
 - using -z noreloc-overflow which actually doesn't seem to apply to
PC32 relocations.
 - Look at all linker options and script format for anything around that.

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

Re: [Xen-devel] [PATCH RFC 13/55] x86/mm: rewrite virt_to_xen_l3e

[Jan Beulich]

>>> On 07.02.19 at 17:44,  wrote:
> @@ -4769,45 +4769,70 @@ void free_xen_pagetable_new(mfn_t mfn)
>  
>  static DEFINE_SPINLOCK(map_pgdir_lock);
>  
> +/*
> + * Given a virtual address, return a pointer to xen's L3 entry. Caller
> + * needs to unmap the pointer.
> + */
>  static l3_pgentry_t *virt_to_xen_l3e(unsigned long v)
>  {
>  l4_pgentry_t *pl4e;
> +l3_pgentry_t *pl3e = NULL;
>  
>  pl4e = _pg_table[l4_table_offset(v)];
>  if ( !(l4e_get_flags(*pl4e) & _PAGE_PRESENT) )
>  {
>  bool locking = system_state > SYS_STATE_boot;
> -l3_pgentry_t *l3t = alloc_xen_pagetable();
> +l3_pgentry_t *l3t;
> +mfn_t mfn;
> +
> +mfn = alloc_xen_pagetable_new();
> +if ( mfn_eq(mfn, INVALID_MFN) )
> +goto out;

Any reason not to use "return NULL" here, avoiding the goto
and label altogether in tis function?

>  static l2_pgentry_t *virt_to_xen_l2e(unsigned long v)
>  {
>  l3_pgentry_t *pl3e;
> +l2_pgentry_t *pl2e = NULL;
>  
>  pl3e = virt_to_xen_l3e(v);
>  if ( !pl3e )
> -return NULL;
> +goto out;

Why not keep this one the way it is?

Jan



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

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

[Laszlo Ersek]

On 04/08/19 16:23, Anthony PERARD wrote:
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/ovmf.git 
> br.platform-xen-pvh-v2
>
> Hi,
>
> I've started to create a Xen specific platform, in OvmfPkg/XenOvmf.dsc
> with the goal to make it work on both Xen HVM and Xen PVH.

The previous version of this feature dates back to Dec 2016 / Jan 2017;
I haven't forgotten about it, and I'm happy that you are adding the
feature as a separate platform DSC, as I requested.

> The first few patches only create the platform and duplicate some code
> from OvmfPkg and the later patches makes OVMF boot in a Xen PVH guest
> and can boot a Linux guest.
>
> After this patch series, I'd like to wait a bit before removing Xen
> support from the OvmfPkg*.dsc, to allow time to switch to the new Xen
> only platform, maybe 1 year.

I welcome this proposal very much. This will eliminate a significant
amount of complexity in the current modules, allow for
easier-to-understand maintenance assignments/responsibilities, and pave
the way for features that are unique to either Xen or QEMU (in
particular in the variable storage area, for which Xen has just received
a dedicated userspace daemon IIRC, and for which -- on QEMU -- I had
attempted to make pflash a conditional hard requirement, in the past,
but failed due to OvmfPkg*.dsc targeting Xen too).

> Question:
>
> Should we start moving these to a different *Pkg? Like it's done for
> ArmPkg and ArmVirtPkg?  Maybe XenPkg.

I'm pretty happy with the current package structure. ArmPkg is for both
physical and virtual hardware. ArmVirtPkg is virt-only, and we already
have separate platform DSCs/FDFs between Xen (ArmVirtXen) and QEMU/KVM
(ArmVirtQemu[Kernel]). Xen- and QEMU/KVM-specific drivers and library
instances peacefully coexist under ArmVirtPkg; the DSCs/FDFs include
them as appropriate.

The same should map nicely to OvmfPkg. x86 stuff that targets both
physical and virtual hardware belongs under PcAtChipsetPkg and
UefiCpuPkg. Virt-only stuff should go under OvmfPkg; Xen-specific and
QEMU/KVM-specific modules can coexist under OvmfPkg. It's sufficient if
the platform DSCs cherry-pick them as appropriate.

And, if there are Xen-specific (but not arch-specific) PEIMs / drivers /
libraries that work alike on ARM and x86, they should go under OvmfPkg,
as ArmVirtPkg can (and already does) pull Xen-only modules from OvmfPkg.
See for example, in ArmVirtXen.dsc:

  
SerialPortLib|OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf
  XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf

  OvmfPkg/XenBusDxe/XenBusDxe.inf
  OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf

> To build and boot:
>
> To build, simply run OvmfPkg/build.sh -p OvmfPkg/XenOvmf.dsc

(1) To stick with the ArmVirt pattern, we should initially call this
platform OvmfXen.

(2) And, once you remove the Xen bits from the current
OvmfPkg*.dsc files, we should likely rename those to OvmfQemu*dsc.

I'll try to process this series in a timely manner. My main focus will
be possible regressions on QEMU/KVM, and formalities (license blocks,
signoffs, edk2 coding style, build issues that I might notice in
review).

I can't provide testing feedback, but xen-devel subscribers (and any
other Xen users too, obviously) are super welcome to test & report
results!

(3) Please file a BZ at  about this
feature, and assign it to yourself. The BZ should keep track of all
versions of the patch series (from the mailing list archive).

(4) Ideally, the release notes for the edk2 stable release in which the
feature will appear, should mention the feature (via linking the BZ):


(5) The BZ should be referenced in all the commit messages.

(6) The new edk2 development mailing list is at:

https://edk2.groups.io/g/devel

Please subscribe there, and resend this series to that address, i.e.
. I'm CC'ing the new address myself, for this
initial response, but I'd prefer the rest of my comments to go only to
the new list (without manually updating the CC list on every response).

Thanks!
Laszlo

> Then use OVMF.fd as a kernel of a pvh guest config file (with
> xl/libxl).
>
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/ovmf.git 
> br.platform-xen-pvh-v2
>
> Anthony PERARD (31):
>   OvmfPkg/ResetSystemLib: Add missing dependency on PciLib
>   OvmfPkg: Create platform XenOvmf
>   OvmfPkg: Introduce XenResetVector
>   OvmfPkg: Introduce XenPlatformPei
>   OvmfPkg/XenOvmf: Creating an ELF header
>   OvmfPkg/XenResetVector: Add new entry point for Xen PVH
>   OvmfPkg/XenResetVector: Saving start of day pointer for PVH guests
>   OvmfPkg/XenResetVector: Allow to jumpstart from either hvmloader or
> PVH
>   OvmfPkg/XenOvmf: use a TimerLib instance that depends only on the CPU
>   OvmfPkg/XenPlatformPei: Detect OVMF_INFO 

Re: [Xen-devel] [PATCH v2 1/3] x86/mm: Introduce altp2m_get_gfn_type_access

[Tamas K Lengyel]

On Mon, Apr 8, 2019 at 2:13 AM Alexandru Stefan ISAILA
 wrote:
>
>
> On 05.04.2019 18:04, Tamas K Lengyel wrote:
> > On Fri, Apr 5, 2019 at 7:25 AM Alexandru Stefan ISAILA
> >  wrote:
> >>
> >> This patch moves common code from p2m_set_altp2m_mem_access() and
> >> p2m_change_altp2m_gfn() into one function
> >>
> >> Signed-off-by: Alexandru Isaila 
> >> ---
> >>   xen/arch/x86/mm/mem_access.c | 30 +++--
> >>   xen/arch/x86/mm/p2m.c| 37 ++--
> >>   xen/include/asm-x86/p2m.h| 23 ++
> >>   3 files changed, 48 insertions(+), 42 deletions(-)
> >>
> >> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
> >> index 56c06a4fc6..608f748a57 100644
> >> --- a/xen/arch/x86/mm/mem_access.c
> >> +++ b/xen/arch/x86/mm/mem_access.c
> >> @@ -265,31 +265,23 @@ int p2m_set_altp2m_mem_access(struct domain *d, 
> >> struct p2m_domain *hp2m,
> >>   unsigned int page_order;
> >>   unsigned long gfn_l = gfn_x(gfn);
> >>   int rc;
> >> +bool found_in_hostp2m;
> >>
> >> -mfn = ap2m->get_entry(ap2m, gfn, , _a, 0, NULL, NULL);
> >> +mfn = altp2m_get_gfn_type_access(ap2m, gfn, , _a, _order, 
> >> _in_hostp2m);
> >>
> >> -/* Check host p2m if no valid entry in alternate */
> >>   if ( !mfn_valid(mfn) )
> >> -{
> >> +return -ESRCH;
> >>
> >> -mfn = __get_gfn_type_access(hp2m, gfn_l, , _a,
> >> -P2M_ALLOC | P2M_UNSHARE, _order, 
> >> 0);
> >> +/* If this is a superpage, copy that first */
> >> +if ( page_order != PAGE_ORDER_4K && found_in_hostp2m )
> >> +{
> >> +unsigned long mask = ~((1UL << page_order) - 1);
> >> +gfn_t gfn2 = _gfn(gfn_l & mask);
> >> +mfn_t mfn2 = _mfn(mfn_x(mfn) & mask);
> >>
> >> -rc = -ESRCH;
> >> -if ( !mfn_valid(mfn) || t != p2m_ram_rw )
> >> +rc = ap2m->set_entry(ap2m, gfn2, mfn2, page_order, t, old_a, 1);
> >> +if ( rc )
> >>   return rc;
> >> -
> >> -/* If this is a superpage, copy that first */
> >> -if ( page_order != PAGE_ORDER_4K )
> >> -{
> >> -unsigned long mask = ~((1UL << page_order) - 1);
> >> -gfn_t gfn2 = _gfn(gfn_l & mask);
> >> -mfn_t mfn2 = _mfn(mfn_x(mfn) & mask);
> >> -
> >> -rc = ap2m->set_entry(ap2m, gfn2, mfn2, page_order, t, old_a, 
> >> 1);
> >> -if ( rc )
> >> -return rc;
> >> -}
> >>   }
> >>
> >>   /*
> >> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> >> index b9bbb8f485..b2a5c0c42e 100644
> >> --- a/xen/arch/x86/mm/p2m.c
> >> +++ b/xen/arch/x86/mm/p2m.c
> >> @@ -2626,6 +2626,7 @@ int p2m_change_altp2m_gfn(struct domain *d, unsigned 
> >> int idx,
> >>   mfn_t mfn;
> >>   unsigned int page_order;
> >>   int rc = -EINVAL;
> >> +bool found_in_hostp2m;
> >>
> >>   if ( idx >= MAX_ALTP2M || d->arch.altp2m_eptp[idx] == 
> >> mfn_x(INVALID_MFN) )
> >>   return rc;
> >> @@ -2636,7 +2637,7 @@ int p2m_change_altp2m_gfn(struct domain *d, unsigned 
> >> int idx,
> >>   p2m_lock(hp2m);
> >>   p2m_lock(ap2m);
> >>
> >> -mfn = ap2m->get_entry(ap2m, old_gfn, , , 0, NULL, NULL);
> >> +mfn = altp2m_get_gfn_type_access(ap2m, old_gfn, , , _order, 
> >> _in_hostp2m);
> >>
> >>   if ( gfn_eq(new_gfn, INVALID_GFN) )
> >>   {
> >> @@ -2648,35 +2649,25 @@ int p2m_change_altp2m_gfn(struct domain *d, 
> >> unsigned int idx,
> >>
> >>   /* Check host p2m if no valid entry in alternate */
> >>   if ( !mfn_valid(mfn) )
> >> -{
> >> -mfn = __get_gfn_type_access(hp2m, gfn_x(old_gfn), , ,
> >> -P2M_ALLOC, _order, 0);
> >> -
> >> -if ( !mfn_valid(mfn) || t != p2m_ram_rw )
> >> -goto out;
> >> + goto out;
> >>
> >> -/* If this is a superpage, copy that first */
> >> -if ( page_order != PAGE_ORDER_4K )
> >> -{
> >> -gfn_t gfn;
> >> -unsigned long mask;
> >> +/* If this is a superpage, copy that first */
> >> +if ( page_order != PAGE_ORDER_4K && found_in_hostp2m )
> >> +{
> >> +gfn_t gfn;
> >> +unsigned long mask;
> >>
> >> -mask = ~((1UL << page_order) - 1);
> >> -gfn = _gfn(gfn_x(old_gfn) & mask);
> >> -mfn = _mfn(mfn_x(mfn) & mask);
> >> +mask = ~((1UL << page_order) - 1);
> >> +gfn = _gfn(gfn_x(old_gfn) & mask);
> >> +mfn = _mfn(mfn_x(mfn) & mask);
> >>
> >> -if ( ap2m->set_entry(ap2m, gfn, mfn, page_order, t, a, 1) )
> >> -goto out;
> >> -}
> >> +if ( ap2m->set_entry(ap2m, gfn, mfn, page_order, t, a, 1) )
> >> +goto out;
> >>   }
> >>
> >> -mfn = ap2m->get_entry(ap2m, new_gfn, , , 0, NULL, NULL);
> >> +mfn = altp2m_get_gfn_type_access(ap2m, new_gfn, , , _order, 
> >> _in_hostp2m);
> 

Re: [Xen-devel] [PATCH RFC v3 2/2] x86/emulate: Send vm_event from emulate

[Jan Beulich]

>>> On 06.02.19 at 13:53,  wrote:
> This patch aims to have mem access vm events sent from the emulator.
> This is useful in the case of page-walks that have to emulate
> instructions in access denied pages.

I'm afraid that I can't make sense of this: How could "page-walks
have to emulate instructions"? Instructions can (and actually will)
cause page walks to occur. And page walks hitting access denied
pages may trigger emulation of the insn having initiated the walk.

> We use hvmemul_map_linear_addr() ro intercept r/w access and
> hvmemul_insn_fetch() to intercept exec access.
> 
> First we try to send a vm event and if the event is sent then emulation
> returns X86EMUL_ACCESS_EXCEPTION. If the event is not sent then the
> emulation goes on as expected.

The meaning of this new emulator return value needs explanation.
I notice its #define is also not accompanied by any comment. And
any addition of a new emulator return code should come with a
discussion of how existing users are affected. I'm not going to
exclude that indeed no other adjustments are necessary, but that's
far from obvious. You may recall that it had taken several iterations
to get the addition of X86EMUL_UNIMPLEMENTED right throughout
the code base.

Overall I guess I'm simply not deeply enough into vm-event to
be able to judge whether / how all of this makes sense.

> @@ -530,6 +532,55 @@ static int hvmemul_do_mmio_addr(paddr_t mmio_gpa,
>  return hvmemul_do_io_addr(1, mmio_gpa, reps, size, dir, df, ram_gpa);
>  }
>  
> +static bool hvmemul_send_vm_event(paddr_t gpa, unsigned long gla, gfn_t gfn,
> +  uint32_t pfec, struct hvm_emulate_ctxt 
> *ctxt)

Why both gpa and gfn?

> @@ -704,6 +756,23 @@ static void *hvmemul_map_linear_addr(
>  
>  if ( pfec & PFEC_write_access )
>  {
> +unsigned long reps = 1;
> +struct hvm_emulate_ctxt old;
> +int rc = 0;
> +paddr_t gpa;
> +
> +old = *hvmemul_ctxt;
> +rc = hvmemul_linear_to_phys(addr, , bytes, ,
> +pfec, hvmemul_ctxt);
> +if ( rc == X86EMUL_EXCEPTION )
> +*hvmemul_ctxt = old;

Something like this - if it is _really_ needed - has to be accompanied
by a justification. I find it questionable though that you really should
need to save/restore the entire context structure.

But I also don't understand why you need to re-do the translation
here: Just above of this hunk you've altered the call to
hvm_translate_get_page() to give you the gfn. And if there was
a reason to re-do it for the sending of the event, then it should
be restricted to that cases, i.e. un-monitored VMs should not be
impacted.

> @@ -1224,7 +1293,35 @@ int hvmemul_insn_fetch(
>  container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
>  /* Careful, as offset can wrap or truncate WRT insn_buf_eip. */
>  uint8_t insn_off = offset - hvmemul_ctxt->insn_buf_eip;
> +paddr_t gpa;
> +uint32_t pfec = PFEC_page_present | PFEC_insn_fetch;
> +unsigned long addr, reps = 1;
> +int rc;
> +struct hvm_emulate_ctxt old;
> +
> +rc = hvmemul_virtual_to_linear(seg, offset, bytes, ,
> +   hvm_access_insn_fetch, hvmemul_ctxt, 
> );

The double translation is as problematic here, but what's worse:

> +if ( rc == X86EMUL_EXCEPTION )
> +{
> +x86_emul_reset_event(ctxt);
> +rc = X86EMUL_OKAY;
> +}

You zap an error here, but ...

> +if ( hvmemul_ctxt->seg_reg[x86_seg_ss].dpl == 3 )
> +pfec |= PFEC_user_mode;
> +
> +old = *hvmemul_ctxt;
> +rc = hvmemul_linear_to_phys(addr, , bytes, ,
> +pfec, hvmemul_ctxt);

... you happily use "addr" here anyway.

> +if ( rc == X86EMUL_EXCEPTION )
> +{
> +*hvmemul_ctxt = old;
> +rc = X86EMUL_OKAY;
> +}
>  
> +if ( gpa && hvmemul_send_vm_event(gpa, addr, gaddr_to_gfn(gpa),
> +  pfec, hvmemul_ctxt) )
> +return X86EMUL_ACCESS_EXCEPTION;

Is there anything rendering gpa being zero an invalid / impossible
situation?

Jan


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

[Xen-devel] [PATCH 3/3] xen-bus / xen-block: add support for event channel polling

[Paul Durrant]

This patch introduces a poll callback for event channel fd-s and uses
this to invoke the channel callback function.

To properly support polling, it is necessary for the event channel callback
function to return a boolean saying whether it has done any useful work or
not. Thus xen_block_dataplane_event() is modified to directly invoke
xen_block_handle_requests() and the latter only returns true if it actually
processes any requests. This also means that the call to qemu_bh_schedule()
is moved into xen_block_complete_aio(), which is more intuitive since the
only reason for doing a deferred poll of the shared ring should be because
there were previously insufficient resources to fully complete a previous
poll.

Signed-off-by: Paul Durrant 
---
Cc: Stefan Hajnoczi 
Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: Kevin Wolf 
Cc: Max Reitz 
---
 hw/block/dataplane/xen-block.c | 17 +
 hw/xen/xen-bus.c   | 11 +--
 include/hw/xen/xen-bus.h   |  2 +-
 3 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c
index 1046f965c4..908bd27bbd 100644
--- a/hw/block/dataplane/xen-block.c
+++ b/hw/block/dataplane/xen-block.c
@@ -317,7 +317,9 @@ static void xen_block_complete_aio(void *opaque, int ret)
 }
 xen_block_release_request(request);
 
-qemu_bh_schedule(dataplane->bh);
+if (dataplane->more_work) {
+qemu_bh_schedule(dataplane->bh);
+}
 
 done:
 aio_context_release(dataplane->ctx);
@@ -514,12 +516,13 @@ static int xen_block_get_request(XenBlockDataPlane 
*dataplane,
  */
 #define IO_PLUG_THRESHOLD 1
 
-static void xen_block_handle_requests(XenBlockDataPlane *dataplane)
+static bool xen_block_handle_requests(XenBlockDataPlane *dataplane)
 {
 RING_IDX rc, rp;
 XenBlockRequest *request;
 int inflight_atstart = dataplane->requests_inflight;
 int batched = 0;
+bool done_something = false;
 
 dataplane->more_work = 0;
 
@@ -551,6 +554,7 @@ static void xen_block_handle_requests(XenBlockDataPlane 
*dataplane)
 }
 xen_block_get_request(dataplane, request, rc);
 dataplane->rings.common.req_cons = ++rc;
+done_something = true;
 
 /* parse them */
 if (xen_block_parse_request(request) != 0) {
@@ -602,10 +606,7 @@ static void xen_block_handle_requests(XenBlockDataPlane 
*dataplane)
 blk_io_unplug(dataplane->blk);
 }
 
-if (dataplane->more_work &&
-dataplane->requests_inflight < dataplane->max_requests) {
-qemu_bh_schedule(dataplane->bh);
-}
+return done_something;
 }
 
 static void xen_block_dataplane_bh(void *opaque)
@@ -617,11 +618,11 @@ static void xen_block_dataplane_bh(void *opaque)
 aio_context_release(dataplane->ctx);
 }
 
-static void xen_block_dataplane_event(void *opaque)
+static bool xen_block_dataplane_event(void *opaque)
 {
 XenBlockDataPlane *dataplane = opaque;
 
-qemu_bh_schedule(dataplane->bh);
+return xen_block_handle_requests(dataplane);
 }
 
 XenBlockDataPlane *xen_block_dataplane_create(XenDevice *xendev,
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index 4f634d1291..c90fc62a8d 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -931,13 +931,20 @@ struct XenEventChannel {
 void *opaque;
 };
 
+static bool xen_device_poll(void *opaque)
+{
+XenEventChannel *channel = opaque;
+
+return channel->handler(channel->opaque);
+}
+
 static void xen_device_event(void *opaque)
 {
 XenEventChannel *channel = opaque;
 unsigned long port = xenevtchn_pending(channel->xeh);
 
 if (port == channel->local_port) {
-channel->handler(channel->opaque);
+xen_device_poll(channel);
 
 xenevtchn_unmask(channel->xeh, port);
 }
@@ -972,7 +979,7 @@ XenEventChannel *xen_device_bind_event_channel(XenDevice 
*xendev,
 
 channel->ctx = ctx;
 aio_set_fd_handler(channel->ctx, xenevtchn_fd(channel->xeh), false,
-   xen_device_event, NULL, NULL, channel);
+   xen_device_event, NULL, xen_device_poll, channel);
 
 QLIST_INSERT_HEAD(>event_channels, channel, list);
 
diff --git a/include/hw/xen/xen-bus.h b/include/hw/xen/xen-bus.h
index 8183b98c7d..1c2d9dfdb8 100644
--- a/include/hw/xen/xen-bus.h
+++ b/include/hw/xen/xen-bus.h
@@ -119,7 +119,7 @@ void xen_device_copy_grant_refs(XenDevice *xendev, bool 
to_domain,
 XenDeviceGrantCopySegment segs[],
 unsigned int nr_segs, Error **errp);
 
-typedef void (*XenEventHandler)(void *opaque);
+typedef bool (*XenEventHandler)(void *opaque);
 
 XenEventChannel *xen_device_bind_event_channel(XenDevice *xendev,
AioContext *ctx,
-- 
2.20.1.2.gb21ebb6


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

[Xen-devel] [PATCH 2/3] xen-bus: allow AioContext to be specified for each event channel

[Paul Durrant]

This patch adds an AioContext parameter to xen_device_bind_event_channel()
and then uses aio_set_fd_handler() to set the callback rather than
qemu_set_fd_handler().

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: Stefan Hajnoczi 
Cc: Kevin Wolf 
Cc: Max Reitz 
---
 hw/block/dataplane/xen-block.c |  2 +-
 hw/xen/xen-bus.c   | 10 +++---
 include/hw/xen/xen-bus.h   |  1 +
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c
index bb8f1186e4..1046f965c4 100644
--- a/hw/block/dataplane/xen-block.c
+++ b/hw/block/dataplane/xen-block.c
@@ -802,7 +802,7 @@ void xen_block_dataplane_start(XenBlockDataPlane *dataplane,
 }
 
 dataplane->event_channel =
-xen_device_bind_event_channel(xendev, event_channel,
+xen_device_bind_event_channel(xendev, dataplane->ctx, event_channel,
   xen_block_dataplane_event, dataplane,
   _err);
 if (local_err) {
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index 9e391492ac..4f634d1291 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -924,6 +924,7 @@ done:
 
 struct XenEventChannel {
 QLIST_ENTRY(XenEventChannel) list;
+AioContext *ctx;
 xenevtchn_handle *xeh;
 evtchn_port_t local_port;
 XenEventHandler handler;
@@ -943,6 +944,7 @@ static void xen_device_event(void *opaque)
 }
 
 XenEventChannel *xen_device_bind_event_channel(XenDevice *xendev,
+   AioContext *ctx,
unsigned int port,
XenEventHandler handler,
void *opaque, Error **errp)
@@ -968,8 +970,9 @@ XenEventChannel *xen_device_bind_event_channel(XenDevice 
*xendev,
 channel->handler = handler;
 channel->opaque = opaque;
 
-qemu_set_fd_handler(xenevtchn_fd(channel->xeh), xen_device_event, NULL,
-channel);
+channel->ctx = ctx;
+aio_set_fd_handler(channel->ctx, xenevtchn_fd(channel->xeh), false,
+   xen_device_event, NULL, NULL, channel);
 
 QLIST_INSERT_HEAD(>event_channels, channel, list);
 
@@ -1010,7 +1013,8 @@ void xen_device_unbind_event_channel(XenDevice *xendev,
 
 QLIST_REMOVE(channel, list);
 
-qemu_set_fd_handler(xenevtchn_fd(channel->xeh), NULL, NULL, NULL);
+aio_set_fd_handler(channel->ctx, xenevtchn_fd(channel->xeh), false,
+   NULL, NULL, NULL, NULL);
 
 if (xenevtchn_unbind(channel->xeh, channel->local_port) < 0) {
 error_setg_errno(errp, errno, "xenevtchn_unbind failed");
diff --git a/include/hw/xen/xen-bus.h b/include/hw/xen/xen-bus.h
index 3315f0de20..8183b98c7d 100644
--- a/include/hw/xen/xen-bus.h
+++ b/include/hw/xen/xen-bus.h
@@ -122,6 +122,7 @@ void xen_device_copy_grant_refs(XenDevice *xendev, bool 
to_domain,
 typedef void (*XenEventHandler)(void *opaque);
 
 XenEventChannel *xen_device_bind_event_channel(XenDevice *xendev,
+   AioContext *ctx,
unsigned int port,
XenEventHandler handler,
void *opaque, Error **errp);
-- 
2.20.1.2.gb21ebb6


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

[Xen-devel] [PATCH 0/3] Support IOThread polling for PV shared rings

[Paul Durrant]

Currently xen-block uses an IOThread to handle AIO but the event channels
are dealt with on QEMU's main thread. This series allows them to be
dealt with in the same context.

Paul Durrant (3):
  xen-bus: use a separate fd for each event channel
  xen-bus: allow AioContext to be specified for each event channel
  xen-bus / xen-block: add support for event channel polling

 hw/block/dataplane/xen-block.c | 19 +++
 hw/xen/xen-bus.c   | 92 +++---
 include/hw/xen/xen-bus.h   |  9 ++--
 3 files changed, 66 insertions(+), 54 deletions(-)
---
Cc: Anthony Perard 
Cc: Kevin Wolf 
Cc: Max Reitz 
Cc: Stefan Hajnoczi 
Cc: Stefano Stabellini 
--
2.20.1.2.gb21ebb6


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

[Xen-devel] [PATCH 1/3] xen-bus: use a separate fd for each event channel

[Paul Durrant]

To better support use of IOThread-s it will be necessary to be able to set
the AioContext for each XenEventChannel and hence it is necessary to open a
separate handle to libxenevtchan for each channel.

This patch stops using NotifierList for event channel callbacks, replacing
that construct by a list of complete XenEventChannel structures. Each of
these now has a xenevtchn_handle pointer in place of the single pointer
previously held in the XenDevice structure. The individual handles are
opened/closed in xen_device_bind/unbind_event_channel(), replacing the
single open/close in xen_device_realize/unrealize().

NOTE: This patch does not add an AioContext parameter to
  xen_device_bind_event_channel(). That will be done in a subsequent
  patch.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 
---
 hw/xen/xen-bus.c | 79 
 include/hw/xen/xen-bus.h |  6 +--
 2 files changed, 42 insertions(+), 43 deletions(-)

diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index 49a725e8c7..9e391492ac 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -923,19 +923,22 @@ done:
 }
 
 struct XenEventChannel {
+QLIST_ENTRY(XenEventChannel) list;
+xenevtchn_handle *xeh;
 evtchn_port_t local_port;
 XenEventHandler handler;
 void *opaque;
-Notifier notifier;
 };
 
-static void event_notify(Notifier *n, void *data)
+static void xen_device_event(void *opaque)
 {
-XenEventChannel *channel = container_of(n, XenEventChannel, notifier);
-unsigned long port = (unsigned long)data;
+XenEventChannel *channel = opaque;
+unsigned long port = xenevtchn_pending(channel->xeh);
 
 if (port == channel->local_port) {
 channel->handler(channel->opaque);
+
+xenevtchn_unmask(channel->xeh, port);
 }
 }
 
@@ -947,24 +950,39 @@ XenEventChannel *xen_device_bind_event_channel(XenDevice 
*xendev,
 XenEventChannel *channel = g_new0(XenEventChannel, 1);
 xenevtchn_port_or_error_t local_port;
 
-local_port = xenevtchn_bind_interdomain(xendev->xeh,
+channel->xeh = xenevtchn_open(NULL, 0);
+if (!channel->xeh) {
+error_setg_errno(errp, errno, "failed xenevtchn_open");
+goto fail;
+}
+
+local_port = xenevtchn_bind_interdomain(channel->xeh,
 xendev->frontend_id,
 port);
 if (local_port < 0) {
 error_setg_errno(errp, errno, "xenevtchn_bind_interdomain failed");
-
-g_free(channel);
-return NULL;
+goto fail;
 }
 
 channel->local_port = local_port;
 channel->handler = handler;
 channel->opaque = opaque;
-channel->notifier.notify = event_notify;
 
-notifier_list_add(>event_notifiers, >notifier);
+qemu_set_fd_handler(xenevtchn_fd(channel->xeh), xen_device_event, NULL,
+channel);
+
+QLIST_INSERT_HEAD(>event_channels, channel, list);
 
 return channel;
+
+fail:
+if (channel->xeh) {
+xenevtchn_close(channel->xeh);
+}
+
+g_free(channel);
+
+return NULL;
 }
 
 void xen_device_notify_event_channel(XenDevice *xendev,
@@ -976,7 +994,7 @@ void xen_device_notify_event_channel(XenDevice *xendev,
 return;
 }
 
-if (xenevtchn_notify(xendev->xeh, channel->local_port) < 0) {
+if (xenevtchn_notify(channel->xeh, channel->local_port) < 0) {
 error_setg_errno(errp, errno, "xenevtchn_notify failed");
 }
 }
@@ -990,12 +1008,15 @@ void xen_device_unbind_event_channel(XenDevice *xendev,
 return;
 }
 
-notifier_remove(>notifier);
+QLIST_REMOVE(channel, list);
 
-if (xenevtchn_unbind(xendev->xeh, channel->local_port) < 0) {
+qemu_set_fd_handler(xenevtchn_fd(channel->xeh), NULL, NULL, NULL);
+
+if (xenevtchn_unbind(channel->xeh, channel->local_port) < 0) {
 error_setg_errno(errp, errno, "xenevtchn_unbind failed");
 }
 
+xenevtchn_close(channel->xeh);
 g_free(channel);
 }
 
@@ -1004,6 +1025,7 @@ static void xen_device_unrealize(DeviceState *dev, Error 
**errp)
 XenDevice *xendev = XEN_DEVICE(dev);
 XenDeviceClass *xendev_class = XEN_DEVICE_GET_CLASS(xendev);
 const char *type = object_get_typename(OBJECT(xendev));
+XenEventChannel *channel, *next;
 
 if (!xendev->name) {
 return;
@@ -1020,15 +1042,14 @@ static void xen_device_unrealize(DeviceState *dev, 
Error **errp)
 xendev_class->unrealize(xendev, errp);
 }
 
+/* Make sure all event channels are cleaned up */
+QLIST_FOREACH_SAFE(channel, >event_channels, list, next) {
+xen_device_unbind_event_channel(xendev, channel, NULL);
+}
+
 xen_device_frontend_destroy(xendev);
 xen_device_backend_destroy(xendev);
 
-if (xendev->xeh) {
-qemu_set_fd_handler(xenevtchn_fd(xendev->xeh), NULL, NULL, NULL);
-xenevtchn_close(xendev->xeh);
-xendev->xeh = NULL;
-}
-
 if 

Re: [Xen-devel] [PATCH v2] xen/timers: Fix memory leak with cpu unplug/plug

[Andrew Cooper]

On 08/04/2019 14:53, Julien Grall wrote:
> Hi Andrew,
>
> On 4/8/19 1:09 PM, Andrew Cooper wrote:
>> On 08/04/2019 12:38, Julien Grall wrote:
>>> Hi,
>>>
>>> On 4/8/19 11:47 AM, Andrew Cooper wrote:
 On 08/04/2019 11:39, Julien Grall wrote:
> Hi,
>
> On 4/8/19 10:39 AM, Andrew Cooper wrote:
>> +    case CPU_RESUME_FAILED:
>> +    if ( !park_offline_cpus && system_state !=
>> SYS_STATE_suspend )
>
> This patch breaks compilation on arm32/arm64 because
> park_offline_cpus
> is not defined:
>
> timer.c: In function 'cpu_callback':
> timer.c:651:15: error: 'park_offline_cpus' undeclared (first use in
> this function)
>    if ( !park_offline_cpus && system_state !=
> SYS_STATE_suspend )
>  ^
>
> What is the purpose of park_offline_cpus?

 Sorry.  I should have waited for a full build test first.

 park_offline_cpus is a workaround for Intel's MCE behaviour, where the
 system will shut down rather than deliver an #MC if machine checking
 isn't configured on all CPUs.

 As a result, we have to start all CPUs, even beyond maxcpus= and
 set up
 machine check handling, and never ever free their stacks, even if we'd
 prefer the CPUs to be offline.
>>>
>>> I am a bit confused, why this is necessary now for the timer and not
>>> in other places of the common code?
>>>

 Are you happy with a

 #define park_offline_cpus false >
 in ARM?
>>>
>>> The name is fairly confusing if you don't know the background.
>>>
>>> But I have to admit that even with your explanation above, I still
>>> don't understand why you need to check park_offline_cpus in the timers.
>>
>> It is all to do with how/when we free per-cpu data.
>>
>> Technically speaking (with the memory leak fixed) the old arrangement
>> ought to function correctly, but the new arrangement is more efficient.
> Where would the free happen in the "less efficient" way?

I don't quite understand the question.

https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg02252.html
is the v1 patch, but that has already been rejected for not using the
up-to-date notifier layout.

~Andrew

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

Re: [Xen-devel] [PATCH 3/3] memory: restrict XENMEM_remove_from_physmap to translated guests

[Jan Beulich]

>>> On 08.04.19 at 13:47,  wrote:
> On 4/2/19 5:10 PM, Jan Beulich wrote:
> On 02.04.19 at 12:26,  wrote:
>>> On 05/03/2019 13:28, Jan Beulich wrote:
 The commit re-introducing it (14eb3b41d0 ["xen: reinstate previously
 unused XENMEM_remove_from_physmap hypercall"]) as well as the one having
 originally introduced it (d818f3cb7c ["hvm: Use main memory for video
 memory"]) and the one then purging it again (78c3097e4f ["Remove unused
 XENMEM_remove_from_physmap"]) make clear that this operation is intended
 for use on HVM (i.e. translated) guests only. Restrict it at least as
 much, because for PV guests documentation (in the public header) does
 not even match the implementation: It talks about GPFN as input, but
 get_page_from_gfn() assumes a GMFN in the non-translated case (and hands
 back the value passed in).

 Also lift the check in XENMEM_add_to_physmap{,_batch} handling up
 directly into top level hypercall handling, and clarify things in the
 public header accordingly.

 Take the liberty and also replace a pointless use of "current" with a
 more efficient use of an existing local variable (or function parameter
 to be precise).

 Signed-off-by: Jan Beulich 
 ---
 TBD: It could be further restricted, disallowing its use by a HVM guest
on itself.
>>>
>>> By HVM guest, do you refer to any auto-translated guest?
>> 
>> Yes - sorry for using an x86 term.
>> 
>>> The interface XENME_remove_from_physmap is used by Arm to remove foreign
>>> mappings from its p2m. There are potentially other space with similar case
>>> (e.g grant-table...).
>> 
>> Oh, I see - this option goes away then.
>> 
 TBD: Is using P2M_ALLOC here really appropriate? It means e.g.
pointlessly populating a PoD slot just to unpopulate it again right
away, with the page then free floating, i.e. no longer available
for use to replace another PoD slot, and (afaict) no longer
accessible by the guest in any way.
 TBD: Is using guest_physmap_remove_page() here really appropriate? It
means that e.g. MMIO pages wouldn't be removed. Going through
guest_remove_page() (while skipping the de-allocation step) would
seem more appropriate to me, which would address the P2M_ALLOC
aspect above as well.
>>>
>>> How is that an issue? Does XENMEM_add_to_physmap allows you to map MMIO
>>> pages?
>> 
>> Well, there's XENMAPSPACE_dev_mmio which xatp handles. But
>> perhaps the MMIO example is more confusing than helpful. The
>> question really just is whether guest_remove_page() shouldn't
>> be used here instead of guest_physmap_remove_page()
> de-allocation step aside, I am not really convinced you can reuse 
> guest_remove_page() here. On x86, the function will not work on certain 
> p2m types. Is it what we really want?

Hmm, I'm confused. Afaics the only two types it refuses a request
for are p2m_invalid and p2m_mmio_dm. These represent cases
where there's no p2m entry anyway, i.e. nothing to remove. Am
I perhaps overlooking something you see?

Or are you referring to the mfn_invalid() check (which isn't x86-
specific)? This ought to be covered by the p2m_is_paging() and
p2m_mmio_direct special cases a few lines up from there. Other
cases with invalid MFNs would indeed represent an error condition
imo.

In the end it's actually quite the opposite that I'm thinking: For
the caller it shouldn't, for example, matter whether the
requested page was paged out. We wouldn't even call
guest_physmap_remove_page() in that case, while
guest_remove_page() would take care of it.

Jan



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

[Xen-devel] [PATCH v2 31/31] OvmfPkg/XenOvmf: use RealTimeClockRuntimeDxe from EmbeddedPkg

[Anthony PERARD]

A Xen PVH guest doesn't have a RTC that OVMF would expect, so
PcatRealTimeClockRuntimeDxe fails to initialize and prevent the firmware
from finish to boot. To prevent that, we will use the
XenRealTimeClockLib from ArmVirtPkg which simply always return the same
time. This will work on both Xen PVH and HVM guests.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---
 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 72d6ea8b29..14ef9ea9f2 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -577,7 +577,10 @@ [Components]
   }
   MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
   MdeModulePkg/Universal/Metronome/Metronome.inf
-  PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
+  EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf {
+
+  
RealTimeClockLib|OvmfPkg/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 9aa998f15f..1b62da2ec5 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -293,7 +293,7 @@ [FV.DXEFV]
 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/XenIoPvhDxe/XenIoPvhDxe.inf
 INF  OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v2 24/31] OvmfPkg/XenPlatformPei: Ignore missing PCI Host Bridge on Xen PVH

[Anthony PERARD]

When the device ID of the host bridge is unknown, check if we are
running as a PVH guest as there is no PCI bus in that case.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---

Notes:
v2:
- Use new XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID macro

 OvmfPkg/Include/OvmfPlatforms.h   | 6 ++
 OvmfPkg/XenPlatformPei/Platform.c | 7 +++
 2 files changed, 13 insertions(+)

diff --git a/OvmfPkg/Include/OvmfPlatforms.h b/OvmfPkg/Include/OvmfPlatforms.h
index cc67f40a88..1ce71e18ec 100644
--- a/OvmfPkg/Include/OvmfPlatforms.h
+++ b/OvmfPkg/Include/OvmfPlatforms.h
@@ -43,4 +43,10 @@
 //
 #define ACPI_TIMER_OFFSET 0x8
 
+//
+// When running OVMF on a Xen PVH guest there is no PCI,
+// so -1 is return for the Host Bridge Device ID.
+//
+#define XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID 0x
+
 #endif
diff --git a/OvmfPkg/XenPlatformPei/Platform.c 
b/OvmfPkg/XenPlatformPei/Platform.c
index 5e6d553ad5..d91cd98bf4 100644
--- a/OvmfPkg/XenPlatformPei/Platform.c
+++ b/OvmfPkg/XenPlatformPei/Platform.c
@@ -278,6 +278,13 @@ MiscInitialization (
   AcpiEnBit  = ICH9_ACPI_CNTL_ACPI_EN;
   break;
 default:
+  if (XenPvhDetected ()) {
+//
+// There is no PCI bus in this case
+//
+PcdSet16S (PcdOvmfHostBridgePciDevId, 
XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID);
+return;
+  }
   DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
 __FUNCTION__, mHostBridgeDevId));
   ASSERT (FALSE);
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v2 19/31] OvmfPkg/XenPlatformPei: Introduce XenPvhDetected

[Anthony PERARD]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenPlatformPei/Platform.h |  5 +
 OvmfPkg/XenPlatformPei/Xen.c  | 13 +
 2 files changed, 18 insertions(+)

diff --git a/OvmfPkg/XenPlatformPei/Platform.h 
b/OvmfPkg/XenPlatformPei/Platform.h
index a524c23a43..c5a139f016 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -105,6 +105,11 @@ XenHvmloaderDetected (
   VOID
   );
 
+BOOLEAN
+XenPvhDetected (
+  VOID
+  );
+
 VOID
 AmdSevInitialize (
   VOID
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index b36eff524d..23ff3102b5 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -217,6 +217,19 @@ XenHvmloaderDetected (
   return (mXenHvmloaderInfo != NULL);
 }
 
+BOOLEAN
+XenPvhDetected (
+  VOID
+  )
+{
+  //
+  // This function should only be used after XenConnect
+  //
+  ASSERT (mXenInfo.VersionMajor != 0);
+
+  return mXenHvmloaderInfo == NULL;
+}
+
 VOID
 XenPublishRamRegions (
   VOID
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v2 22/31] OvmfPkg/XenPlatformPei: Rework memory detection

[Anthony PERARD]

When running as a Xen PVH guest, there is no CMOS to read the memory
size from.  Rework GetSystemMemorySize(Below|Above)4gb() so they can
works without CMOS by reading the e820 table.

Rework XenPublishRamRegions for PVH, handle the Reserve type and explain
about the ACPI type. MTRR settings aren't modified anymore, on HVM, it's
already done by hvmloader, on PVH it is supposed to have sane default.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---

Notes:
About MTRR, should we redo the setting in OVMF? Even if in both case of
PVH and HVM, something would have setup the default type to write back
and handle a few other ranges like PCI hole, hvmloader for HVM or and
libxc I think for PVH.

(For PVH, it's in the spec as well
https://xenbits.xenproject.org/docs/unstable/misc/pvh.html#mtrr )

 OvmfPkg/XenPlatformPei/Platform.h  |  6 ++
 OvmfPkg/XenPlatformPei/MemDetect.c | 71 
 OvmfPkg/XenPlatformPei/Xen.c   | 47 +
 3 files changed, 111 insertions(+), 13 deletions(-)

diff --git a/OvmfPkg/XenPlatformPei/Platform.h 
b/OvmfPkg/XenPlatformPei/Platform.h
index c5a139f016..d6d93eab2d 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -120,6 +120,12 @@ XenPublishRamRegions (
   VOID
   );
 
+EFI_STATUS
+XenGetE820Map (
+  EFI_E820_ENTRY64 **Entries,
+  UINT32 *Count
+  );
+
 extern EFI_BOOT_MODE mBootMode;
 
 extern UINT8 mPhysMemAddressWidth;
diff --git a/OvmfPkg/XenPlatformPei/MemDetect.c 
b/OvmfPkg/XenPlatformPei/MemDetect.c
index db3d387d1c..0c066d518b 100644
--- a/OvmfPkg/XenPlatformPei/MemDetect.c
+++ b/OvmfPkg/XenPlatformPei/MemDetect.c
@@ -102,6 +102,47 @@ Q35TsegMbytesInitialization (
   mQ35TsegMbytes = ExtendedTsegMbytes;
 }
 
+STATIC
+UINT64
+GetHighestSystemMemoryAddress (
+  BOOLEAN   Below4gb
+  )
+{
+  EFI_E820_ENTRY64*E820Map;
+  UINT32  E820EntriesCount;
+  EFI_E820_ENTRY64*Entry;
+  EFI_STATUS  Status;
+  UINT32  Loop;
+  UINT64  HighestAddress;
+  UINT64  EntryEnd;
+
+  HighestAddress = 0;
+
+  Status = XenGetE820Map (, );
+  ASSERT_EFI_ERROR (Status);
+
+  for (Loop = 0; Loop < E820EntriesCount; Loop++) {
+Entry = E820Map + Loop;
+EntryEnd = Entry->BaseAddr + Entry->Length;
+
+if (Entry->Type == EfiAcpiAddressRangeMemory &&
+EntryEnd > HighestAddress) {
+
+  if (Below4gb && (EntryEnd <= BASE_4GB)) {
+HighestAddress = EntryEnd;
+  } else if (!Below4gb && (EntryEnd >= BASE_4GB)) {
+HighestAddress = EntryEnd;
+  }
+}
+  }
+
+  //
+  // Round down the end address.
+  //
+  HighestAddress &= ~(UINT64)EFI_PAGE_MASK;
+
+  return HighestAddress;
+}
 
 UINT32
 GetSystemMemorySizeBelow4gb (
@@ -111,6 +152,19 @@ GetSystemMemorySizeBelow4gb (
   UINT8 Cmos0x34;
   UINT8 Cmos0x35;
 
+  //
+  // In PVH case, there is no CMOS, we have to calculate the memory size
+  // from parsing the E820
+  //
+  if (XenPvhDetected ()) {
+UINT64  HighestAddress;
+
+HighestAddress = GetHighestSystemMemoryAddress (TRUE);
+ASSERT (HighestAddress > 0 && HighestAddress <= BASE_4GB);
+
+return HighestAddress;
+  }
+
   //
   // CMOS 0x34/0x35 specifies the system memory above 16 MB.
   // * CMOS(0x35) is the high byte
@@ -135,6 +189,23 @@ GetSystemMemorySizeAbove4gb (
   UINT32 Size;
   UINTN  CmosIndex;
 
+  //
+  // In PVH case, there is no CMOS, we have to calculate the memory size
+  // from parsing the E820
+  //
+  if (XenPvhDetected ()) {
+UINT64  HighestAddress;
+
+HighestAddress = GetHighestSystemMemoryAddress (FALSE);
+ASSERT (HighestAddress == 0 || HighestAddress >= BASE_4GB);
+
+if (HighestAddress >= BASE_4GB) {
+  HighestAddress -= BASE_4GB;
+}
+
+return HighestAddress;
+  }
+
   //
   // CMOS 0x5b-0x5d specifies the system memory above 4GB MB.
   // * CMOS(0x5d) is the most significant size byte
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index f8cee671d8..7b503f2c4e 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -282,6 +282,8 @@ XenPublishRamRegions (
   EFI_E820_ENTRY64  *E820Map;
   UINT32E820EntriesCount;
   EFI_STATUSStatus;
+  EFI_E820_ENTRY64 *Entry;
+  UINTN Index;
 
   DEBUG ((EFI_D_INFO, "Using memory map provided by Xen\n"));
 
@@ -290,26 +292,45 @@ XenPublishRamRegions (
   //
   E820EntriesCount = 0;
   Status = XenGetE820Map (, );
-
   ASSERT_EFI_ERROR (Status);
 
-  if (E820EntriesCount > 0) {
-EFI_E820_ENTRY64 *Entry;
-UINT32 Loop;
+  for (Index = 0; Index < E820EntriesCount; Index++) {
+UINT64 Base;
+UINT64 End;
 
-for (Loop = 0; Loop < E820EntriesCount; Loop++) {
-  Entry = E820Map + Loop;
+Entry = [Index];
 
+
+//
+// Round up the start address, and round down the end address.
+//
+Base = ALIGN_VALUE (Entry->BaseAddr, (UINT64)EFI_PAGE_SIZE);
+End = (Entry->BaseAddr + 

[Xen-devel] [PATCH v2 14/31] OvmfPkg/AcpiPlatformDxe: Use PVH RSDP if exist

[Anthony PERARD]

If the firmware have been started via the PVH entry point, a RSDP
pointer would have been provided. Use it.

Also, use XenDetect() from the new XenPlatformLib.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/OvmfPkgIa32.dsc |  1 +
 OvmfPkg/OvmfPkgIa32X64.dsc  |  1 +
 OvmfPkg/OvmfPkgX64.dsc  |  1 +
 OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf |  2 +-
 OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h  |  6 +--
 OvmfPkg/AcpiPlatformDxe/Xen.c   | 41 
 6 files changed, 22 insertions(+), 30 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index f55ab5a3d2..cab9764cab 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -205,6 +205,7 @@ [LibraryClasses]
   SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
   
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
   XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+  XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
 
 !if $(TPM2_ENABLE) == TRUE
   Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 5c9bdf034e..a156358690 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -210,6 +210,7 @@ [LibraryClasses]
   SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
   
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
   XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+  XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
 
 !if $(TPM2_ENABLE) == TRUE
   Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 2943e9e8af..9d8dc442b4 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -210,6 +210,7 @@ [LibraryClasses]
   SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
   
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
   XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+  XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
 
 !if $(TPM2_ENABLE) == TRUE
   Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf 
b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
index 8440e7b343..ca54a3bd9e 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
@@ -51,13 +51,13 @@ [LibraryClasses]
   DebugLib
   UefiBootServicesTableLib
   UefiDriverEntryPoint
-  HobLib
   QemuFwCfgLib
   QemuFwCfgS3Lib
   MemoryAllocationLib
   BaseLib
   DxeServicesTableLib
   OrderedCollectionLib
+  XenPlatformLib
 
 [Protocols]
   gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h 
b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
index 83b981ee00..85f37128dd 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -58,11 +59,6 @@ QemuInstallAcpiTable (
   OUT  UINTN *TableKey
   );
 
-BOOLEAN
-XenDetected (
-  VOID
-  );
-
 EFI_STATUS
 EFIAPI
 InstallXenTables (
diff --git a/OvmfPkg/AcpiPlatformDxe/Xen.c b/OvmfPkg/AcpiPlatformDxe/Xen.c
index 618ac58b42..7e9a7797d7 100644
--- a/OvmfPkg/AcpiPlatformDxe/Xen.c
+++ b/OvmfPkg/AcpiPlatformDxe/Xen.c
@@ -15,8 +15,6 @@
 **/ 
 
 #include "AcpiPlatform.h"
-#include 
-#include 
 #include 
 
 #define XEN_ACPI_PHYSICAL_ADDRESS 0x000EA020
@@ -24,28 +22,6 @@
 
 EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER  *XenAcpiRsdpStructurePtr = NULL;
 
-/**
-  This function detects if OVMF is running on Xen.
-
-**/
-BOOLEAN
-XenDetected (
-  VOID
-  )
-{
-  EFI_HOB_GUID_TYPE *GuidHob;
-
-  //
-  // See if a XenInfo HOB is available
-  //
-  GuidHob = GetFirstGuidHob ();
-  if (GuidHob == NULL) {
-return FALSE;
-  }
-
-  return TRUE;
-}
-
 /**
   Get the address of Xen ACPI Root System Description Pointer (RSDP)
   structure.
@@ -66,10 +42,27 @@ GetXenAcpiRsdp (
   EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER   *RsdpStructurePtr;
   UINT8  *XenAcpiPtr;
   UINT8  Sum;
+  EFI_XEN_INFO   *XenInfo;
 
   //
   // Detect the RSDP structure
   //
+
+  //
+  // First look for PVH one
+  //
+  XenInfo = XenGetInfoHOB ();
+  ASSERT (XenInfo != NULL);
+  if (XenInfo->RsdpPvh != NULL) {
+DEBUG ((DEBUG_INFO, "AcpiPlatformDxe: Use ACPI RSDP table at 0x%08x\n",
+XenInfo->RsdpPvh));
+*RsdpPtr = XenInfo->RsdpPvh;
+

[Xen-devel] [PATCH v2 17/31] OvmfPkg/XenPlatformPei: Reserve hvmloader's memory only when it as runned

[Anthony PERARD]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenPlatformPei/Xen.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 89933ec3e9..22c7a22c88 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -275,7 +275,9 @@ InitializeXen (
   // Reserve away HVMLOADER reserved memory [0xFC00,0xFD00).
   // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
   //
-  AddReservedMemoryBaseSizeHob (0xFC00, 0x100, FALSE);
+  if (XenHvmloaderDetected ()) {
+AddReservedMemoryBaseSizeHob (0xFC00, 0x100, FALSE);
+  }
 
   PcdStatus = PcdSetBoolS (PcdPciDisableBusEnumeration, TRUE);
   ASSERT_RETURN_ERROR (PcdStatus);
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v2 27/31] OvmfPkg/XenOvmf: Introduce XenTimerDxe

[Anthony PERARD]

"PcAtChipsetPkg/8254TimerDxe" is replaced with a Xen-specific
EFI_TIMER_ARCH_PROTOCOL implementation. Also remove
8259InterruptControllerDxe as it is not used anymore.

This Timer uses the local APIC timer as time source as it can work on
both a Xen PVH guest and an HVM one.

Based on the "PcAtChipsetPkg/8254TimerDxe" implementation.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---

Notes:
v2:
- Use InitializeApicTimer instead of WriteLocalApicReg
- rework comments (remove many that don't apply)
- remove unused includes, and libs
- have a macro to the timervector.
- cleanup, copyright
- rework calculation of TimerCount, value to be use by the APIC timer
- check for overflow of TimerPeriod, with the apic timer, the period can
  be up to about 42s on Xen (or even higher by changing the DivideValue).

 OvmfPkg/XenOvmf.dsc
  |   3 +-
 OvmfPkg/XenOvmf.fdf
  |   3 +-
 PcAtChipsetPkg/8254TimerDxe/8254Timer.inf => 
OvmfPkg/XenTimerDxe/XenTimerDxe.inf |  27 +++---
 PcAtChipsetPkg/8254TimerDxe/Timer.h => OvmfPkg/XenTimerDxe/XenTimerDxe.h   
  |  32 +++
 PcAtChipsetPkg/8254TimerDxe/Timer.c => OvmfPkg/XenTimerDxe/XenTimerDxe.c   
  | 100 ++--
 5 files changed, 55 insertions(+), 110 deletions(-)

diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index 54601c697f..35af05715b 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -560,10 +560,9 @@ [Components]
   MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
 
   MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
-  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
+  OvmfPkg/XenTimerDxe/XenTimerDxe.inf
   UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
   UefiCpuPkg/CpuDxe/CpuDxe.inf
-  PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
   OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
   OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
   MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index f9e58befd6..d614bdce1d 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -284,10 +284,9 @@ [FV.DXEFV]
 INF  MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
 INF  MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
 INF  MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
-INF  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
+INF  OvmfPkg/XenTimerDxe/XenTimerDxe.inf
 INF  UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
 INF  UefiCpuPkg/CpuDxe/CpuDxe.inf
-INF  PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
 INF  OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
 INF  OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
 INF  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
diff --git a/PcAtChipsetPkg/8254TimerDxe/8254Timer.inf 
b/OvmfPkg/XenTimerDxe/XenTimerDxe.inf
similarity index 64%
copy from PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
copy to OvmfPkg/XenTimerDxe/XenTimerDxe.inf
index 46cf01de39..5ad80b9368 100644
--- a/PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
+++ b/OvmfPkg/XenTimerDxe/XenTimerDxe.inf
@@ -1,7 +1,9 @@
 ## @file
-# 8254 timer driver that provides Timer Arch protocol.
+# Local APIC timer driver that provides Timer Arch protocol.
+#
+# Copyright (c) 2005 - 2014, Intel Corporation. All rights reserved.
+# Copyright (c) 2019, Citrix Systems, Inc.
 #
-# Copyright (c) 2005 - 2018, 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
@@ -14,9 +16,8 @@
 
 [Defines]
   INF_VERSION= 0x00010005
-  BASE_NAME  = Timer
-  MODULE_UNI_FILE= Timer.uni
-  FILE_GUID  = f2765dec-6b41-11d5-8e71-00902707b35e
+  BASE_NAME  = XenTimerDxe
+  FILE_GUID  = 52fe8196-f9de-4d07-b22f-51f77a0e7c41
   MODULE_TYPE= DXE_DRIVER
   VERSION_STRING = 1.0
 
@@ -25,24 +26,24 @@ [Defines]
 [Packages]
   MdePkg/MdePkg.dec
   IntelFrameworkPkg/IntelFrameworkPkg.dec
+  UefiCpuPkg/UefiCpuPkg.dec
+  OvmfPkg/OvmfPkg.dec
 
 [LibraryClasses]
   UefiBootServicesTableLib
   BaseLib
   DebugLib
   UefiDriverEntryPoint
-  IoLib
+  LocalApicLib
 
 [Sources]
-  Timer.h
-  Timer.c
+  XenTimerDxe.h
+  XenTimerDxe.c
 
 [Protocols]
   gEfiCpuArchProtocolGuid   ## CONSUMES
-  gEfiLegacy8259ProtocolGuid## CONSUMES
   gEfiTimerArchProtocolGuid ## PRODUCES
-
+[Pcd]
+  gEfiMdePkgTokenSpaceGuid.PcdFSBClock  ## CONSUMES
 [Depex]
-  gEfiCpuArchProtocolGuid AND gEfiLegacy8259ProtocolGuid
-[UserExtensions.TianoCore."ExtraFiles"]
-  TimerExtra.uni
+  gEfiCpuArchProtocolGuid
diff --git a/PcAtChipsetPkg/8254TimerDxe/Timer.h 

[Xen-devel] [PATCH v2 15/31] OvmfPkg/XenHypercallLib: Enable it in PEIM

[Anthony PERARD]

Allow to use Xen hypercalls earlier, during the PEIM stage, but
XenHypercallLibReInit() must be called once the XenInfo HOB is created
with the HyperPage setup.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf |  2 +-
 OvmfPkg/XenPlatformPei/XenPlatformPei.inf   |  1 +
 OvmfPkg/Include/Library/XenHypercallLib.h   | 12 
 OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c   | 11 +++
 OvmfPkg/XenPlatformPei/Xen.c|  7 +++
 5 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf 
b/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
index d268e540fe..e0a1889171 100644
--- a/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+++ b/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
@@ -21,7 +21,7 @@ [Defines]
   CONSTRUCTOR= XenHypercallLibInit
 
 [Defines.IA32, Defines.X64]
-  LIBRARY_CLASS  = XenHypercallLib|DXE_DRIVER UEFI_DRIVER
+  LIBRARY_CLASS  = XenHypercallLib|PEIM DXE_DRIVER UEFI_DRIVER
 
 [Defines.ARM, Defines.AARCH64]
   LIBRARY_CLASS  = XenHypercallLib
diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf 
b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index 1870e39208..bc6065a709 100644
--- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -66,6 +66,7 @@ [LibraryClasses]
   MtrrLib
   MemEncryptSevLib
   PcdLib
+  XenHypercallLib
 
 [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase
diff --git a/OvmfPkg/Include/Library/XenHypercallLib.h 
b/OvmfPkg/Include/Library/XenHypercallLib.h
index 36e3344e2f..38e64ab108 100644
--- a/OvmfPkg/Include/Library/XenHypercallLib.h
+++ b/OvmfPkg/Include/Library/XenHypercallLib.h
@@ -16,6 +16,18 @@
 #ifndef __XEN_HYPERCALL_LIB_H__
 #define __XEN_HYPERCALL_LIB_H__
 
+/**
+  To call when the gEfiXenInfoGuid HOB became available after the library init
+  function has already been executed.
+
+  This allow to make hypercall in the PEIM stage.
+**/
+VOID
+EFIAPI
+XenHypercallLibReInit (
+  VOID
+  );
+
 /**
   Check if the Xen Hypercall library is able to make calls to the Xen
   hypervisor.
diff --git a/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c 
b/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c
index 7cb7f46c9b..2ac7254759 100644
--- a/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c
+++ b/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c
@@ -78,6 +78,17 @@ XenHypercallLibInit (
   return RETURN_SUCCESS;
 }
 
+VOID
+EFIAPI
+XenHypercallLibReInit (
+  VOID
+  )
+{
+  if (HyperPage == NULL) {
+XenHypercallLibInit();
+  }
+}
+
 /**
   This function will put the two arguments in the right place (registers) and
   invoke the hypercall identified by HypercallID.
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index fb01094ba9..9d9e9f8020 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "Platform.h"
 #include "Xen.h"
@@ -157,6 +158,12 @@ XenConnect (
 sizeof(mXenInfo)
 );
 
+  //
+  // Initialize the XenHypercall library, now that the XenInfo HOB is
+  // available
+  //
+  XenHypercallLibReInit ();
+
   return EFI_SUCCESS;
 }
 
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v2 23/31] OvmfPkg/XenPlatformPei: Reserve VGA memory region, to boot Linux

[Anthony PERARD]

Linux panic if this region isn't reserved.

When Linux is booted on EFI system, it expects the memory at 0xa to
_not_ be conventional memory. Otherwise a variable isn't initialised
properly and Linux panic when a virtual console/terminal is asked to be
created.

See for more detail:
https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg02139.html

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenPlatformPei/Xen.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 7b503f2c4e..25f12c2f9c 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -294,6 +294,12 @@ XenPublishRamRegions (
   Status = XenGetE820Map (, );
   ASSERT_EFI_ERROR (Status);
 
+  AddMemoryBaseSizeHob (0, 0xA);
+  //
+  // Video memory + Legacy BIOS region, to allow Linux to boot.
+  //
+  AddReservedMemoryBaseSizeHob (0xA, BASE_1MB - 0xA, TRUE);
+
   for (Index = 0; Index < E820EntriesCount; Index++) {
 UINT64 Base;
 UINT64 End;
@@ -307,6 +313,16 @@ XenPublishRamRegions (
 Base = ALIGN_VALUE (Entry->BaseAddr, (UINT64)EFI_PAGE_SIZE);
 End = (Entry->BaseAddr + Entry->Length) & ~(UINT64)EFI_PAGE_MASK;
 
+//
+// Ignore the first 1MB, this is handled before the loop.
+//
+if (Base < BASE_1MB) {
+  Base = BASE_1MB;
+}
+if (Base >= End) {
+  continue;
+}
+
 switch (Entry->Type) {
 case EfiAcpiAddressRangeMemory:
   AddMemoryRangeHob (Base, End);
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v2 18/31] OvmfPkg/XenPlatformPei: Setup HyperPages earlier

[Anthony PERARD]

We are going to need to make an hypercall in order to retreive the E820
table from the hypervisor before been able to setup the memory.

Calling XenConnect earlier will allow to setup the XenHypercallLib
earlier to allow to make hypercalls.

While here, add some comments in XenConnect().

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenPlatformPei/Platform.h |  5 +
 OvmfPkg/XenPlatformPei/Platform.c |  2 ++
 OvmfPkg/XenPlatformPei/Xen.c  | 23 ++--
 3 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/OvmfPkg/XenPlatformPei/Platform.h 
b/OvmfPkg/XenPlatformPei/Platform.h
index 5565d47e34..a524c23a43 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -85,6 +85,11 @@ InstallClearCacheCallback (
   VOID
   );
 
+EFI_STATUS
+XenConnect (
+  VOID
+  );
+
 EFI_STATUS
 InitializeXen (
   VOID
diff --git a/OvmfPkg/XenPlatformPei/Platform.c 
b/OvmfPkg/XenPlatformPei/Platform.c
index 2d567a4760..5e6d553ad5 100644
--- a/OvmfPkg/XenPlatformPei/Platform.c
+++ b/OvmfPkg/XenPlatformPei/Platform.c
@@ -421,6 +421,8 @@ InitializeXenPlatform (
 CpuDeadLoop ();
   }
 
+  XenConnect ();
+
   BootModeInitialization ();
   AddressWidthInitialization ();
 
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 22c7a22c88..b36eff524d 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -78,14 +78,11 @@ XenGetE820Map (
 /**
   Connects to the Hypervisor.
  
-  @param  XenLeaf CPUID index used to connect.
-
   @return EFI_STATUS
 
 **/
 EFI_STATUS
 XenConnect (
-  UINT32 XenLeaf
   )
 {
   UINT32 Index;
@@ -96,7 +93,13 @@ XenConnect (
   CHAR8 Sig[sizeof (Info->Signature) + 1];
   UINT32 *PVHResetVectorData;
 
-  AsmCpuid (XenLeaf + 2, , , NULL, NULL);
+  ASSERT (mXenLeaf != 0);
+
+  //
+  // Prepare HyperPages to be able to make hypercalls
+  //
+
+  AsmCpuid (mXenLeaf + 2, , , NULL, NULL);
   mXenInfo.HyperPages = AllocatePages (TransferPages);
   if (!mXenInfo.HyperPages) {
 return EFI_OUT_OF_RESOURCES;
@@ -108,7 +111,11 @@ XenConnect (
(Index << EFI_PAGE_SHIFT) + Index);
   }
 
-  AsmCpuid (XenLeaf + 1, , NULL, NULL, NULL);
+  //
+  // Find out the Xen version
+  //
+
+  AsmCpuid (mXenLeaf + 1, , NULL, NULL, NULL);
   DEBUG ((EFI_D_ERROR, "Detected Xen version %d.%d\n",
   XenVersion >> 16, XenVersion & 0x));
   mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
@@ -265,12 +272,6 @@ InitializeXen (
 {
   RETURN_STATUS PcdStatus;
 
-  if (mXenLeaf == 0) {
-return EFI_NOT_FOUND;
-  }
-
-  XenConnect (mXenLeaf);
-
   //
   // Reserve away HVMLOADER reserved memory [0xFC00,0xFD00).
   // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v2 16/31] OvmfPkg/XenPlatformPei: Introduce XenHvmloaderDetected

[Anthony PERARD]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenPlatformPei/Platform.h | 5 +
 OvmfPkg/XenPlatformPei/Xen.c  | 7 +++
 2 files changed, 12 insertions(+)

diff --git a/OvmfPkg/XenPlatformPei/Platform.h 
b/OvmfPkg/XenPlatformPei/Platform.h
index 6ccd5eb66c..5565d47e34 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -95,6 +95,11 @@ XenDetect (
   VOID
   );
 
+BOOLEAN
+XenHvmloaderDetected (
+  VOID
+  );
+
 VOID
 AmdSevInitialize (
   VOID
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 9d9e9f8020..89933ec3e9 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -202,6 +202,13 @@ XenDetect (
   return FALSE;
 }
 
+BOOLEAN
+XenHvmloaderDetected (
+  VOID
+  )
+{
+  return (mXenHvmloaderInfo != NULL);
+}
 
 VOID
 XenPublishRamRegions (
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v2 29/31] OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables

[Anthony PERARD]

This "device" use XenIoMmioLib to reserve some space to be use by the
Grant Tables.

The call is only done if it is necessary, we simply detect if the guest
is probably PVH, as in this case there is currently no PCI bus, and no
PCI Xen platform device which would start the XenIoPciDxe and allocate
the space for the Grant Tables.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---

Notes:
v2:
- do allocation in EntryPoint like the other user of XenIoMmioLib.
- allocate memory instead of hardcoded addr.
- cleanup, add copyright
- detect if we are running in PVH mode

 OvmfPkg/XenOvmf.dsc  |  2 ++
 OvmfPkg/XenOvmf.fdf  |  1 +
 OvmfPkg/{XenIoPciDxe/XenIoPciDxe.inf => XenIoPvhDxe/XenIoPvhDxe.inf} | 26 
+-
 OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c| 38 

 4 files changed, 49 insertions(+), 18 deletions(-)

diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index a26f611058..72d6ea8b29 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -199,6 +199,7 @@ [LibraryClasses]
   
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
   XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
   XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
+  XenIoMmioLib|OvmfPkg/Library/XenIoMmioLib/XenIoMmioLib.inf
 
   
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
 
@@ -596,6 +597,7 @@ [Components]
   
NULL|IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
 !endif
   }
+  OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
   OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
   OvmfPkg/XenBusDxe/XenBusDxe.inf
   OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index e078c7b405..9aa998f15f 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -295,6 +295,7 @@ [FV.DXEFV]
 INF  MdeModulePkg/Universal/Metronome/Metronome.inf
 INF  PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
 
+INF  OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
 INF  OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
 INF  OvmfPkg/XenBusDxe/XenBusDxe.inf
 INF  OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
diff --git a/OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf 
b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
similarity index 56%
copy from OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
copy to OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
index b32075a381..985b6d54b7 100644
--- a/OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
+++ b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
@@ -1,7 +1,7 @@
 ## @file
-#  Driver for the virtual Xen PCI device
+#  Driver for the XenIo protocol
 #
-#  Copyright (C) 2015, Linaro Ltd.
+#  Copyright (c) 2019, Citrix Systems, Inc.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
@@ -15,31 +15,21 @@
 
 [Defines]
   INF_VERSION   = 0x00010005
-  BASE_NAME = XenIoPciDxe
-  FILE_GUID = cf569f50-de44-4f54-b4d7-f4ae25cda599
+  BASE_NAME = XenIoPvhDxe
+  FILE_GUID = 7a567cc4-0e75-4d7a-a305-c3db109b53ad
   MODULE_TYPE   = UEFI_DRIVER
   VERSION_STRING= 1.0
-  ENTRY_POINT   = XenIoPciDeviceEntryPoint
+  ENTRY_POINT   = InitializeXenIoPvhDxe
 
 [Packages]
   MdePkg/MdePkg.dec
   OvmfPkg/OvmfPkg.dec
 
 [Sources]
-  XenIoPciDxe.c
+  XenIoPvhDxe.c
 
 [LibraryClasses]
   UefiDriverEntryPoint
-  UefiBootServicesTableLib
   MemoryAllocationLib
-  BaseMemoryLib
-  BaseLib
-  UefiLib
-  DebugLib
-
-[Protocols]
-  gEfiDriverBindingProtocolGuid
-  gEfiPciIoProtocolGuid
-  gEfiComponentName2ProtocolGuid
-  gEfiComponentNameProtocolGuid
-  gXenIoProtocolGuid
+  XenIoMmioLib
+  XenPlatformLib
diff --git a/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c 
b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
new file mode 100644
index 00..f2113b768c
--- /dev/null
+++ b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
@@ -0,0 +1,38 @@
+/** @file
+
+  Driver for the XenIo protocol
+
+  This driver simply allocate space for the grant tables.
+
+  Copyright (c) 2019, Citrix Systems, Inc.
+
+  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 
+
+EFI_STATUS
+EFIAPI
+InitializeXenIoPvhDxe (
+  IN EFI_HANDLE   ImageHandle,
+  IN EFI_SYSTEM_TABLE *SystemTable
+  )
+{
+  if (XenPvhDetected ()) {
+EFI_HANDLE Handle;
+
+Handle = NULL;
+ 

[Xen-devel] [PATCH v2 26/31] OvmfPkg/XenOvmf: Override PcdFSBClock to Xen vLAPIC timer frequency

[Anthony PERARD]

That value is used by SecPeiDxeTimerLibCpu, the TimerLib implementation.
It will also be used by XenTimerDxe.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---

Notes:
new patch in v2.

 OvmfPkg/XenOvmf.dsc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index 9529b4834f..54601c697f 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -452,6 +452,9 @@ [PcdsFixedAtBuild]
   # 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 }
 
+  ## Xen vlapic's frequence is 100 MHz
+  gEfiMdePkgTokenSpaceGuid.PcdFSBClock|1
+
 

 #
 # Pcd Dynamic Section - list of all EDK II PCD Entries defined by this Platform
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v2 30/31] OvmfPkg: Move XenRealTimeClockLib from ArmVirtPkg

[Anthony PERARD]

So it can be used from the OvmfPkg by the following patch,
"OvmfPkg/XenOvmf: use RealTimeClockRuntimeDxe from EmbeddedPkg"

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---
 ArmVirtPkg/ArmVirtXen.dsc   | 
2 +-
 {ArmVirtPkg => OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf | 0
 {ArmVirtPkg => OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.c   | 0
 3 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
index a3688ae2cb..d5d8d79561 100644
--- a/ArmVirtPkg/ArmVirtXen.dsc
+++ b/ArmVirtPkg/ArmVirtXen.dsc
@@ -33,7 +33,7 @@ [Defines]
 
 [LibraryClasses]
   
SerialPortLib|OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf
-  
RealTimeClockLib|ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
+  RealTimeClockLib|OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
   XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
 
   
ArmGenericTimerCounterLib|ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/XenArmGenericTimerVirtCounterLib.inf
diff --git a/ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf 
b/OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
similarity index 100%
rename from ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
rename to OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
diff --git a/ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c 
b/OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
similarity index 100%
rename from ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
rename to OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v2 21/31] OvmfPkg/XenPlatformPei: Get E820 table via hypercall ...

[Anthony PERARD]

.. when hvmloader haven't runned before OVMF. The only way left to get
an E820 table is to ask Xen via an hypercall, the call can only be made
once so keep the result cached for later.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenPlatformPei/Xen.c | 46 +++-
 1 file changed, 45 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 23ff3102b5..f8cee671d8 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "Platform.h"
 #include "Xen.h"
@@ -46,6 +47,8 @@ EFI_XEN_INFO mXenInfo;
 // Only the E820 table is used by OVMF.
 //
 EFI_XEN_OVMF_INFO *mXenHvmloaderInfo;
+EFI_E820_ENTRY64 E820Entries[128];
+UINT32 E820EntriesCount;
 
 /**
   Returns E820 map provided by Xen
@@ -61,6 +64,12 @@ XenGetE820Map (
   UINT32 *Count
   )
 {
+  INTN ReturnCode;
+  xen_memory_map_t Parameters;
+  UINTN LoopIndex;
+  UINTN Index;
+  EFI_E820_ENTRY64 TmpEntry;
+
   //
   // Get E820 produced by hvmloader
   //
@@ -72,7 +81,42 @@ XenGetE820Map (
 return EFI_SUCCESS;
   }
 
-  return EFI_NOT_FOUND;
+  //
+  // Otherwise, get the E820 table from the Xen hypervisor
+  //
+
+  if (E820EntriesCount > 0) {
+*Entries = E820Entries;
+*Count = E820EntriesCount;
+return EFI_SUCCESS;
+  }
+
+  Parameters.nr_entries = 128;
+  set_xen_guest_handle (Parameters.buffer, E820Entries);
+
+  // Returns a errno
+  ReturnCode = XenHypercallMemoryOp (XENMEM_memory_map, );
+  ASSERT (ReturnCode == 0);
+
+  E820EntriesCount = Parameters.nr_entries;
+
+  //
+  // Sort E820 entries
+  //
+  for (LoopIndex = 1; LoopIndex < E820EntriesCount; LoopIndex++) {
+for (Index = LoopIndex; Index < E820EntriesCount; Index++) {
+  if (E820Entries[Index - 1].BaseAddr > E820Entries[Index].BaseAddr) {
+TmpEntry = E820Entries[Index];
+E820Entries[Index] = E820Entries[Index - 1];
+E820Entries[Index - 1] = TmpEntry;
+  }
+}
+  }
+
+  *Count = E820EntriesCount;
+  *Entries = E820Entries;
+
+  return EFI_SUCCESS;
 }
 
 /**
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v2 13/31] OvmfPkg/Library/XenPlatformLib: New library

[Anthony PERARD]

The purpose of XenPlatformPei is to regroup the few functions that are
used in several places to detect if Xen is detected, and to get the
XenInfo HOB.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenOvmf.dsc
   |  1 +
 MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf => 
OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf | 27 +++
 OvmfPkg/Include/Library/XenPlatformLib.h   
   | 59 +++
 OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c
   | 75 
 4 files changed, 150 insertions(+), 12 deletions(-)

diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index cc51bac3be..9529b4834f 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -198,6 +198,7 @@ [LibraryClasses]
   SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
   
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
   XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+  XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
 
   
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
 
diff --git a/MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf 
b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
similarity index 56%
copy from MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
copy to OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
index 4fd4874595..ca078f7263 100644
--- a/MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
+++ b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
@@ -1,7 +1,10 @@
 ## @file
-# Null implementation of the SMBUS Library.
+#  Get information about Xen
 #
-# Copyright (c) 2013 - 2018, Intel Corporation. All rights reserved.
+#  This library simply allow to find out if OVMF is running under Xen and
+#  allow to get more information when it is the case.
+#
+#  Copyright (c) 2019, Citrix Systems, Inc.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
@@ -10,26 +13,26 @@
 #  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  = BaseSmbusLibNull
-  MODULE_UNI_FILE= BaseSmbusLibNull.uni
-  FILE_GUID  = E2ECA273-A1C0-407E-9A5C-F10C55142196
+  BASE_NAME  = XenPlatformLib
+  FILE_GUID  = DB54DBB7-8142-4EE5-9364-78C824B582EB
   MODULE_TYPE= BASE
   VERSION_STRING = 1.0
-  LIBRARY_CLASS  = SmbusLib
-
-#
-#  VALID_ARCHITECTURES   = IA32 X64 EBC
-#
+  LIBRARY_CLASS  = XenPlatformLib
 
 [Sources]
-  BaseSmbusLibNull.c
+  XenPlatformLib.c
 
 [Packages]
   MdePkg/MdePkg.dec
+  OvmfPkg/OvmfPkg.dec
 
 [LibraryClasses]
-  DebugLib
+  HobLib
+
+[Guids]
+  gEfiXenInfoGuid
diff --git a/OvmfPkg/Include/Library/XenPlatformLib.h 
b/OvmfPkg/Include/Library/XenPlatformLib.h
new file mode 100644
index 00..8f57450575
--- /dev/null
+++ b/OvmfPkg/Include/Library/XenPlatformLib.h
@@ -0,0 +1,59 @@
+/** @file
+*  Get information about Xen
+*
+*  This library simply allow to find out if OVMF is running under Xen and
+*  allow to get more information when it is the case.
+*
+*  Copyright (c) 2019, Citrix Systems, Inc.
+*
+*  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 _XEN_PLATFORM_LIB_H_
+#define _XEN_PLATFORM_LIB_H_
+
+#include 
+
+/**
+  This function detects if OVMF is running on Xen.
+
+  @retval TRUEOVMF is running on Xen
+  @retval FALSE   Xen as not been detected
+**/
+BOOLEAN
+EFIAPI
+XenDetected (
+  VOID
+  );
+
+/**
+  This function detect if OVMF have started via the PVH entry point.
+
+  @retval TRUE  PVH entry point as been used
+  @retval FALSE OVMF have started via the HVM route
+**/
+BOOLEAN
+EFIAPI
+XenPvhDetected (
+  VOID
+  );
+
+/**
+  This function return a pointer to the XenInfo HOB.
+
+  @return  XenInfo pointer or NULL if not available
+**/
+EFI_XEN_INFO *
+EFIAPI
+XenGetInfoHOB (
+  VOID
+  );
+
+#endif
diff --git a/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c 
b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c
new file mode 100644

[Xen-devel] [PATCH v2 10/31] OvmfPkg/XenPlatformPei: Detect OVMF_INFO from hvmloader

[Anthony PERARD]

This struct is only useful to retrieve the E820 table. The
mXenHvmloaderInfo isn't used yet, but will be use in a further patch to
retrieve the E820 table.

Also remove the unused pointer from the XenInfo HOB as that information
is only useful in the XenPlatformPei.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/Include/Guid/XenInfo.h |  4 
 OvmfPkg/PlatformPei/Xen.c  |  3 ---
 OvmfPkg/XenPlatformPei/Xen.c   | 23 ++--
 3 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/OvmfPkg/Include/Guid/XenInfo.h b/OvmfPkg/Include/Guid/XenInfo.h
index d512b0b63f..5d4579f244 100644
--- a/OvmfPkg/Include/Guid/XenInfo.h
+++ b/OvmfPkg/Include/Guid/XenInfo.h
@@ -24,10 +24,6 @@ typedef struct {
   ///
   VOID *HyperPages;
   ///
-  /// Location of the hvm_info page.
-  ///
-  VOID *HvmInfo;
-  ///
   /// Hypervisor major version.
   ///
   UINT16 VersionMajor;
diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/Xen.c
index ab38f97a67..75181be2fd 100644
--- a/OvmfPkg/PlatformPei/Xen.c
+++ b/OvmfPkg/PlatformPei/Xen.c
@@ -104,9 +104,6 @@ XenConnect (
   mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
   mXenInfo.VersionMinor = (UINT16)(XenVersion & 0x);
 
-  /* TBD: Locate hvm_info and reserve it away. */
-  mXenInfo.HvmInfo = NULL;
-
   BuildGuidDataHob (
 ,
 ,
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 7c82e5b69b..a866641b67 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -39,6 +39,12 @@ STATIC UINT32 mXenLeaf = 0;
 
 EFI_XEN_INFO mXenInfo;
 
+//
+// Location of the firmware info struct setup by hvmloader.
+// Only the E820 table is used by OVMF.
+//
+EFI_XEN_OVMF_INFO *mXenHvmloaderInfo;
+
 /**
   Returns E820 map provided by Xen
 
@@ -84,6 +90,8 @@ XenConnect (
   UINT32 TransferReg;
   UINT32 TransferPages;
   UINT32 XenVersion;
+  EFI_XEN_OVMF_INFO *Info;
+  CHAR8 Sig[sizeof (Info->Signature) + 1];
 
   AsmCpuid (XenLeaf + 2, , , NULL, NULL);
   mXenInfo.HyperPages = AllocatePages (TransferPages);
@@ -103,8 +111,19 @@ XenConnect (
   mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
   mXenInfo.VersionMinor = (UINT16)(XenVersion & 0x);
 
-  /* TBD: Locate hvm_info and reserve it away. */
-  mXenInfo.HvmInfo = NULL;
+  //
+  // Check if there are information left by hvmloader
+  //
+
+  Info = (EFI_XEN_OVMF_INFO *)(UINTN) OVMF_INFO_PHYSICAL_ADDRESS;
+  // Copy the signature, and make it null-terminated.
+  AsciiStrnCpyS(Sig, sizeof (Sig),
+(CHAR8 *) >Signature, sizeof (Info->Signature));
+  if (AsciiStrCmp (Sig, "XenHVMOVMF") == 0) {
+mXenHvmloaderInfo = Info;
+  } else {
+mXenHvmloaderInfo = NULL;
+  }
 
   BuildGuidDataHob (
 ,
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v2 20/31] OvmfPkg: Import XENMEM_memory_map hypercall to Xen/memory.h

[Anthony PERARD]

This is copied over from the public header of the Xen Project, with the
type name modified to build on OVMF.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/Include/IndustryStandard/Xen/memory.h | 23 
 1 file changed, 23 insertions(+)

diff --git a/OvmfPkg/Include/IndustryStandard/Xen/memory.h 
b/OvmfPkg/Include/IndustryStandard/Xen/memory.h
index 020155962c..b00a87097d 100644
--- a/OvmfPkg/Include/IndustryStandard/Xen/memory.h
+++ b/OvmfPkg/Include/IndustryStandard/Xen/memory.h
@@ -81,6 +81,29 @@ struct xen_remove_from_physmap {
 typedef struct xen_remove_from_physmap xen_remove_from_physmap_t;
 DEFINE_XEN_GUEST_HANDLE(xen_remove_from_physmap_t);
 
+/*
+ * Returns the pseudo-physical memory map as it was when the domain
+ * was started (specified by XENMEM_set_memory_map).
+ * arg == addr of xen_memory_map_t.
+ */
+#define XENMEM_memory_map   9
+struct xen_memory_map {
+/*
+ * On call the number of entries which can be stored in buffer. On
+ * return the number of entries which have been stored in
+ * buffer.
+ */
+UINT32 nr_entries;
+
+/*
+ * Entries in the buffer are in the same format as returned by the
+ * BIOS INT 0x15 EAX=0xE820 call.
+ */
+XEN_GUEST_HANDLE(void) buffer;
+};
+typedef struct xen_memory_map xen_memory_map_t;
+DEFINE_XEN_GUEST_HANDLE(xen_memory_map_t);
+
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
 
 /*
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v2 25/31] OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen PVH

[Anthony PERARD]

When running on PVH without PCI bus, the XenPlatformPei will set
PcdOvmfHostBridgePciDevId to XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index 12303fb0f1..1a6d47732e 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -1213,6 +1213,11 @@ PciAcpiInitialization (
   PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6a), 0x0b); // G
   PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6b), 0x0b); // H
   break;
+case XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID:
+  //
+  // There are no PCI bus in this case.
+  //
+  return;
 default:
   DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
 __FUNCTION__, mHostBridgeDevId));
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v2 28/31] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn

[Anthony PERARD]

On a Xen PVH guest, none of the existing serial or console interface
works, so we add a new one, based on XenConsoleSerialPortLib, and
implemeted via SerialDxe.

That a simple console implementation that can works on both PVH guest
and HVM guests, even if it rarely going to be use on HVM.

Have PlatformBootManagerLib look for the new console, when running as a
Xen guest.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---

Notes:
v2:
- Use MdeModulePkg/Universal/SerialDxe instead of something new.
- Have PlatformInitializeConsole() look for it by using the
  known-in-advance device path for the xen console in the
  PLATFORM_CONSOLE_CONNECT_ENTRY.

 OvmfPkg/XenOvmf.dsc   |  4 ++
 OvmfPkg/XenOvmf.fdf   |  1 +
 OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |  4 ++
 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h  |  1 +
 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c  | 10 +++-
 OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c | 59 

 6 files changed, 78 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index 35af05715b..a26f611058 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -599,6 +599,10 @@ [Components]
   OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
   OvmfPkg/XenBusDxe/XenBusDxe.inf
   OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
+  MdeModulePkg/Universal/SerialDxe/SerialDxe.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 d614bdce1d..e078c7b405 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -298,6 +298,7 @@ [FV.DXEFV]
 INF  OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
 INF  OvmfPkg/XenBusDxe/XenBusDxe.inf
 INF  OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
+INF  MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
 
 INF  MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
 INF  
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index c41aaeef3f..7dd0683cd2 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -67,6 +67,10 @@ [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
   gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile
+  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
+  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
+  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity   ## CONSUMES
+  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
 
 [Pcd.IA32, Pcd.X64]
   gEfiMdePkgTokenSpaceGuid.PcdFSBClock
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h 
b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
index 4948ca6518..2ab1a76f6a 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
@@ -172,6 +172,7 @@ typedef struct {
 #define CONSOLE_IN  BIT1
 #define STD_ERROR   BIT2
 extern PLATFORM_CONSOLE_CONNECT_ENTRY  gPlatformConsole[];
+extern PLATFORM_CONSOLE_CONNECT_ENTRY  gXenPlatformConsole[];
 
 //
 // Platform BDS Functions
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index 1a6d47732e..f186060f34 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -85,6 +85,13 @@ InstallDevicePathCallback (
   VOID
   );
 
+STATIC
+BOOLEAN
+XenDetected (
+  VOID
+  );
+
+
 VOID
 PlatformRegisterFvBootOption (
   EFI_GUID *FileGuid,
@@ -404,7 +411,8 @@ PlatformBootManagerBeforeConsole (
   //
   EfiBootManagerDispatchDeferredImages ();
 
-  PlatformInitializeConsole (gPlatformConsole);
+  PlatformInitializeConsole (
+XenDetected() ? gXenPlatformConsole : gPlatformConsole);
   PcdStatus = PcdSet16S (PcdPlatformBootTimeOut,
 GetFrontPageTimeoutFromQemu ());
   ASSERT_RETURN_ERROR (PcdStatus);
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c 
b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
index 1250a6d351..4179370c81 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
@@ -16,6 +16,11 @@
 #include "BdsPlatform.h"
 #include 
 
+#define 

[Xen-devel] [PATCH v2 12/31] OvmfPkg/XenPlatformPei: Grab RSDP from PVH guest start of day struct

[Anthony PERARD]

Check if there's a start of the day struct provided to PVH guest, save
the ACPI RSDP address for later.

This patch import import arch-x86/hvm/start_info.h from xen.git.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenPlatformPei/XenPlatformPei.inf  |   3 +
 OvmfPkg/Include/Guid/XenInfo.h |   4 +
 OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h | 159 

 OvmfPkg/XenPlatformPei/Xen.c   |  26 
 4 files changed, 192 insertions(+)

diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf 
b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index c8d25c115f..1870e39208 100644
--- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -91,6 +91,9 @@ [Pcd]
   gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy
   gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
 
+  gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtr
+  gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtrSize
+
 [FixedPcd]
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
 
diff --git a/OvmfPkg/Include/Guid/XenInfo.h b/OvmfPkg/Include/Guid/XenInfo.h
index 5d4579f244..d9c09080bb 100644
--- a/OvmfPkg/Include/Guid/XenInfo.h
+++ b/OvmfPkg/Include/Guid/XenInfo.h
@@ -31,6 +31,10 @@ typedef struct {
   /// Hypervisor minor version.
   ///
   UINT16 VersionMinor;
+  ///
+  /// Pointer to the RSDP found in the hvm_start_info provided to a PVH guest
+  ///
+  VOID *RsdpPvh;
 } EFI_XEN_INFO;
 
 extern EFI_GUID gEfiXenInfoGuid;
diff --git a/OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h 
b/OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h
new file mode 100644
index 00..71bff7dc37
--- /dev/null
+++ b/OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h
@@ -0,0 +1,159 @@
+/*
+ * 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) 2016, Citrix Systems, Inc.
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
+#define __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
+
+/*
+ * Start of day structure passed to PVH guests and to HVM guests in %ebx.
+ *
+ * NOTE: nothing will be loaded at physical address 0, so a 0 value in any
+ * of the address fields should be treated as not present.
+ *
+ *  0 ++
+ *| magic  | Contains the magic value XEN_HVM_START_MAGIC_VALUE
+ *|| ("xEn3" with the 0x80 bit of the "E" set).
+ *  4 ++
+ *| version| Version of this structure. Current version is 1. New
+ *|| versions are guaranteed to be backwards-compatible.
+ *  8 ++
+ *| flags  | SIF_xxx flags.
+ * 12 ++
+ *| nr_modules | Number of modules passed to the kernel.
+ * 16 ++
+ *| modlist_paddr  | Physical address of an array of modules
+ *|| (layout of the structure below).
+ * 24 ++
+ *| cmdline_paddr  | Physical address of the command line,
+ *|| a zero-terminated ASCII string.
+ * 32 ++
+ *| rsdp_paddr | Physical address of the RSDP ACPI data structure.
+ * 40 ++
+ *| memmap_paddr   | Physical address of the (optional) memory map. Only
+ *|| present in version 1 and newer of the structure.
+ * 48 ++
+ *| memmap_entries | Number of entries in the memory map table. Zero
+ *|| if there is no memory map being provided. Only
+ *|| present in version 1 and newer of the structure.
+ * 52 ++
+ *| reserved   | Version 1 and newer only.
+ * 56 ++
+ *
+ * The layout of each entry in the module structure is the following:
+ *
+ *  0 ++
+ *| paddr  | Physical address of the 

[Xen-devel] [PATCH v2 11/31] OvmfPkg/XenPlatformPei: Use mXenHvmloaderInfo to get E820

[Anthony PERARD]

Use the already checked pointer mXenHvmloaderInfo to retrieve the E820
table produced by hvmloader.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenPlatformPei/Xen.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index a866641b67..df906b6be5 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -59,18 +59,18 @@ XenGetE820Map (
   UINT32 *Count
   )
 {
-  EFI_XEN_OVMF_INFO *Info =
-(EFI_XEN_OVMF_INFO *)(UINTN) OVMF_INFO_PHYSICAL_ADDRESS;
+  //
+  // Get E820 produced by hvmloader
+  //
+  if (mXenHvmloaderInfo != NULL) {
+ASSERT (mXenHvmloaderInfo->E820 < MAX_ADDRESS);
+*Entries = (EFI_E820_ENTRY64 *)(UINTN) mXenHvmloaderInfo->E820;
+*Count = mXenHvmloaderInfo->E820EntriesCount;
 
-  if (AsciiStrCmp ((CHAR8 *) Info->Signature, "XenHVMOVMF")) {
-return EFI_NOT_FOUND;
+return EFI_SUCCESS;
   }
 
-  ASSERT (Info->E820 < MAX_ADDRESS);
-  *Entries = (EFI_E820_ENTRY64 *)(UINTN) Info->E820;
-  *Count = Info->E820EntriesCount;
-
-  return EFI_SUCCESS;
+  return EFI_NOT_FOUND;
 }
 
 /**
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v2 04/31] OvmfPkg: Introduce XenPlatformPei

[Anthony PERARD]

A copy of OvmfPkg/PlatformPei without some of QEMU specific
initialization, Xen does not support QemuFwCfg.

This new module will be adjusted to accommodate Xen PVH.

fw_cfg dependents that have been removed, which are dynamically skipped
when running PlatformPei 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
fw_cfg "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 FeatureControl.c as there is nothing been executed)

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

Xen related changes:
- Have removed the module variable mXen, as it should be always true.
- Have the platform PEI initialization fails if Xen has not been
  detected.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenOvmf.dsc|   
2 +-
 OvmfPkg/XenOvmf.fdf|   
2 +-
 OvmfPkg/{PlatformPei/PlatformPei.inf => XenPlatformPei/XenPlatformPei.inf} |  
28 +-
 OvmfPkg/{PlatformPei => XenPlatformPei}/Cmos.h |   
2 +
 OvmfPkg/{PlatformPei => XenPlatformPei}/Platform.h |  
13 +-
 OvmfPkg/{PlatformPei => XenPlatformPei}/Xen.h  |   0
 OvmfPkg/{PlatformPei => XenPlatformPei}/AmdSev.c   |  
30 +-
 OvmfPkg/{PlatformPei => XenPlatformPei}/ClearCache.c   |   
1 +
 OvmfPkg/{PlatformPei => XenPlatformPei}/Cmos.c |   
2 +
 OvmfPkg/{PlatformPei => XenPlatformPei}/Fv.c   |  
26 +-
 OvmfPkg/XenPlatformPei/MemDetect.c | 
427 
 OvmfPkg/{PlatformPei => XenPlatformPei}/Platform.c | 
246 +--
 OvmfPkg/{PlatformPei => XenPlatformPei}/Xen.c  |   
8 +-
 13 files changed, 453 insertions(+), 334 deletions(-)

diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index 6161133fa8..7b8a1fdf6b 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -531,7 +531,7 @@ [Components]
   }
   MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
 
-  OvmfPkg/PlatformPei/PlatformPei.inf
+  OvmfPkg/XenPlatformPei/XenPlatformPei.inf
   UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
   UefiCpuPkg/CpuMpPei/CpuMpPei.inf
 
diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index 292cf4b492..295e30ca3f 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -158,7 +158,7 @@ [FV.PEIFV]
 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
 INF  UefiCpuPkg/CpuMpPei/CpuMpPei.inf
diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
similarity index 69%
copy from OvmfPkg/PlatformPei/PlatformPei.inf
copy to OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index 5c8dd0fe6d..c8d25c115f 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -3,6 +3,7 @@
 #
 #  This module provides platform specific function to detect boot mode.
 #  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2019, Citrix Systems, Inc.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
@@ -16,11 +17,11 @@
 
 [Defines]
   INF_VERSION= 0x00010005
-  BASE_NAME  = PlatformPei
-  FILE_GUID  = 222c386d-5abc-4fb4-b124-fbb82488acf4
+  BASE_NAME  = XenPlatformPei
+  FILE_GUID  = f112a6ee-993a-4f0b-8295-e52029d9b4ba
   MODULE_TYPE= PEIM
   VERSION_STRING = 1.0
-  ENTRY_POINT= 

[Xen-devel] [PATCH v2 06/31] OvmfPkg/XenResetVector: Add new entry point for Xen PVH

[Anthony PERARD]

This one enter directly in 32bits

Information on the expected state of the machine when this entry point
is used can be found at:
https://xenbits.xenproject.org/docs/unstable/misc/pvh.html

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---
 {UefiCpuPkg/ResetVector/Vtf0 => 
OvmfPkg/XenResetVector}/Ia16/ResetVectorVtf0.asm | 18 +++-
 OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm 
  | 47 
 OvmfPkg/XenResetVector/XenResetVector.nasmb
  |  1 +
 3 files changed, 65 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm 
b/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
similarity index 76%
copy from UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm
copy to OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
index 142d9f3212..46eec66859 100644
--- a/UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm
+++ b/OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm
@@ -3,6 +3,8 @@
 ; First code executed by processor after resetting.
 ;
 ; Copyright (c) 2008 - 2014, Intel Corporation. All rights reserved.
+; Copyright (c) 2019, Citrix Systems, Inc.
+;
 ; 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
@@ -27,9 +29,23 @@ ALIGN   16
 ; located just below 0x1 (4GB) in the firmware device.
 ;
 %ifdef ALIGN_TOP_TO_4K_FOR_PAGING
-TIMES (0x1000 - ($ - EndOfPageTables) - 0x20) DB 0
+TIMES (0x1000 - ($ - EndOfPageTables) - (fourGigabytes - 
xenPVHEntryPoint)) DB 0
 %endif
 
+BITS32
+xenPVHEntryPoint:
+;
+; Entry point to use when running as a Xen PVH guest. (0xffd0)
+;
+; Description of the expected state of the machine when this entry point is
+; used can be found at:
+; https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
+;
+jmp xenPVHMain
+
+BITS16
+ALIGN   16
+
 applicationProcessorEntryPoint:
 ;
 ; Application Processors entry point
diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm 
b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
new file mode 100644
index 00..c4802bf4d1
--- /dev/null
+++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
@@ -0,0 +1,47 @@
+;--
+; @file
+; An entry point use by Xen when a guest is started in PVH mode.
+;
+; Copyright (c) 2019, Citrix Systems, Inc.
+;
+; 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.
+;
+;--
+
+BITS32
+
+xenPVHMain:
+mov di, 'BP'
+
+; ESP -  Initial value of the EAX register (BIST: Built-in Self Test)
+mov esp, eax
+
+cli
+
+mov ebx, ADDR_OF(gdtr)
+lgdt[ebx]
+
+mov eax, SEC_DEFAULT_CR0
+mov cr0, eax
+
+jmp LINEAR_CODE_SEL:ADDR_OF(.jmpToNewCodeSeg)
+.jmpToNewCodeSeg:
+
+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
+
+; return to the Main16
+OneTimeCallRet TransitionFromReal16To32BitFlat
diff --git a/OvmfPkg/XenResetVector/XenResetVector.nasmb 
b/OvmfPkg/XenResetVector/XenResetVector.nasmb
index 49f2bab001..d5a791c139 100644
--- a/OvmfPkg/XenResetVector/XenResetVector.nasmb
+++ b/OvmfPkg/XenResetVector/XenResetVector.nasmb
@@ -70,6 +70,7 @@
 %include "Ia16/Init16.asm"
 
 %include "Main.asm"
+%include "Ia32/XenPVHMain.asm"
 
 %include "Ia16/ResetVectorVtf0.asm"
 
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v2 08/31] OvmfPkg/XenResetVector: Allow to jumpstart from either hvmloader or PVH

[Anthony PERARD]

This patch allows the ResetVector to be run indenpendently from build
time addresses.

The goal of the patch is to avoid having to create RAM just below 4G
when creating a Xen PVH guest while been compatible with the way
hvmloader currently load OVMF, just below 4G.

Only the new PVH entry point will do the calculation.

The ResetVector will figure out its current running address by creating
a temporary stack, make a call and calculate the difference between the
build time address and the address at run time.

This patch copies and make the necessary modification to some other asm
files:
- copy of UefiCpuPkg/.../Flat32ToFlat64.asm:
  Allow Transition32FlatTo64Flat to been runnned from anywhere in memory
_ copy of UefiCpuPkg/../SearchForBfvBase.asm:
  Add a extra parameter to indicate where to start the search for the
  boot firmware volume.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm 
   |  3 ++
 {UefiCpuPkg/ResetVector/Vtf0 => 
OvmfPkg/XenResetVector}/Ia32/Flat32ToFlat64.asm   | 25 ++--
 {UefiCpuPkg/ResetVector/Vtf0 => 
OvmfPkg/XenResetVector}/Ia32/SearchForBfvBase.asm | 19 +
 OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm 
   | 30 ++--
 4 files changed, 66 insertions(+), 11 deletions(-)

diff --git a/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm 
b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
index e22e92c8a6..eebced6ced 100644
--- a/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
+++ b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
@@ -61,6 +61,9 @@ jumpTo32BitAndLandHere:
 mov gs, ax
 mov ss, ax
 
+; parameter for Flat32SearchForBfvBase
+xor eax, eax ; Start searching from top of 4GB for BfvBase
+
 OneTimeCallRet TransitionFromReal16To32BitFlat
 
 ALIGN   2
diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia32/Flat32ToFlat64.asm 
b/OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm
similarity index 69%
copy from UefiCpuPkg/ResetVector/Vtf0/Ia32/Flat32ToFlat64.asm
copy to OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm
index 5b6b375330..ca03ea43e0 100644
--- a/UefiCpuPkg/ResetVector/Vtf0/Ia32/Flat32ToFlat64.asm
+++ b/OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm
@@ -3,6 +3,8 @@
 ; Transition from 32 bit flat protected mode into 64 bit flat protected mode
 ;
 ; Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.
+; Copyright (c) 2019, Citrix Systems, Inc.
+;
 ; 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
@@ -16,7 +18,7 @@
 BITS32
 
 ;
-; Modified:  EAX
+; Modified:  EAX, EBX, ECX, EDX, ESP
 ;
 Transition32FlatTo64Flat:
 
@@ -35,10 +37,29 @@ Transition32FlatTo64Flat:
 bts eax, 31 ; set PG
 mov cr0, eax; enable paging
 
-jmp LINEAR_CODE64_SEL:ADDR_OF(jumpTo64BitAndLandHere)
+; backup ESP
+mov ebx, esp
+
+;; recalculate delta
+mov esp, PVH_SPACE(16)
+call.delta
+.delta:
+pop edx
+sub edx, ADDR_OF(.delta)
+
+; push return addr and seg to the stack, then return far
+pushdword LINEAR_CODE64_SEL
+mov eax, ADDR_OF(jumpTo64BitAndLandHere)
+add eax, edx ; add delta
+pusheax
+retf
+
 BITS64
 jumpTo64BitAndLandHere:
 
+; restore ESP
+mov esp, ebx
+
 debugShowPostCode POSTCODE_64BIT_MODE
 
 OneTimeCallRet Transition32FlatTo64Flat
diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia32/SearchForBfvBase.asm 
b/OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm
similarity index 83%
copy from UefiCpuPkg/ResetVector/Vtf0/Ia32/SearchForBfvBase.asm
copy to OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm
index d0c2d8c39c..0519e05601 100644
--- a/UefiCpuPkg/ResetVector/Vtf0/Ia32/SearchForBfvBase.asm
+++ b/OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm
@@ -3,6 +3,8 @@
 ; Search for the Boot Firmware Volume (BFV) base address
 ;
 ; Copyright (c) 2008 - 2009, Intel Corporation. All rights reserved.
+; Copyright (c) 2019, Citrix Systems, Inc.
+;
 ; 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
@@ -23,22 +25,26 @@
 BITS32
 
 ;
-; Modified:  EAX, EBX
+; Modified:  EAX, EBX, ECX
 ; Preserved: EDI, ESP
 ;
+; @param[in]   EAX  Start search from here
 ; @param[out]  EBP  Address of Boot Firmware Volume (BFV)
 ;
 Flat32SearchForBfvBase:
 
-xor eax, eax
+mov ecx, eax
 searchingForBfvHeaderLoop:
 ;
-; We check for a firmware volume at every 4KB address in the top 16MB
-; just below 4GB.  (Addresses at 0xffHHH000 where H is any hex digit.)
+; We check for a firmware 

[Xen-devel] [PATCH v2 09/31] OvmfPkg/XenOvmf: use a TimerLib instance that depends only on the CPU

[Anthony PERARD]

ACPI Timer does not work in a PVH guest, but local APIC works on both
PVH and HVM.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenOvmf.dsc | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index 7b8a1fdf6b..cc51bac3be 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -104,7 +104,7 @@ [SkuIds]
 

 [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
@@ -205,7 +205,7 @@ [LibraryClasses.common]
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
 
 [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
@@ -284,7 +284,7 @@ [LibraryClasses.common.DXE_CORE]
 
 [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
@@ -301,7 +301,7 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
 
 [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
@@ -316,7 +316,7 @@ [LibraryClasses.common.UEFI_DRIVER]
 
 [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
@@ -344,7 +344,7 @@ [LibraryClasses.common.DXE_DRIVER]
 
 [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
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v2 02/31] OvmfPkg: Create platform XenOvmf

[Anthony PERARD]

This is a copy of OvmfX64, removing VirtIO and some SMM.

This new platform will be changed to make it works on two types of Xen
guest: HVM and PVH.

Compare to OvmfX64, this patch:

- changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
- removed: VirtioLib class resolution
- removed: all UEFI_DRIVER modules for virtio devices
- removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
- removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
- removed: Everything related to SMM_REQUIRE==true
- removed: Everything related to SECURE_BOOT_ENABLE==true
- removed: Everything related to TPM2_ENABLE==true
- changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
- changed: default FD_SIZE_IN_KB to 2M.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/{OvmfPkgX64.dsc => XenOvmf.dsc} | 202 +---
 OvmfPkg/{OvmfPkgIa32X64.fdf => XenOvmf.fdf} |  72 +--
 2 files changed, 12 insertions(+), 262 deletions(-)

diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/XenOvmf.dsc
similarity index 79%
copy from OvmfPkg/OvmfPkgX64.dsc
copy to OvmfPkg/XenOvmf.dsc
index 2943e9e8af..bfe9190735 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -3,6 +3,7 @@
 #
 #  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 #  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
+#  Copyright (c) 2019, Citrix Systems, Inc.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
@@ -21,26 +22,22 @@
 

 [Defines]
   PLATFORM_NAME  = Ovmf
-  PLATFORM_GUID  = 5a9e7754-d81b-49ea-85ad-69eaa7b1539b
+  PLATFORM_GUID  = e3aa4fbe-9459-482d-bd40-d3f3b5f89d6e
   PLATFORM_VERSION   = 0.1
   DSC_SPECIFICATION  = 0x00010005
-  OUTPUT_DIRECTORY   = Build/OvmfX64
+  OUTPUT_DIRECTORY   = Build/XenOvmf
   SUPPORTED_ARCHITECTURES= X64
   BUILD_TARGETS  = NOOPT|DEBUG|RELEASE
   SKUID_IDENTIFIER   = DEFAULT
-  FLASH_DEFINITION   = OvmfPkg/OvmfPkgX64.fdf
+  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
   DEFINE TLS_ENABLE  = FALSE
-  DEFINE TPM2_ENABLE = FALSE
-  DEFINE TPM2_CONFIG_ENABLE  = FALSE
   DEFINE USE_LEGACY_ISA_STACK= FALSE
 
   #
@@ -57,7 +54,7 @@ [Defines]
 !ifdef $(FD_SIZE_4MB)
   DEFINE FD_SIZE_IN_KB   = 4096
 !else
-  DEFINE FD_SIZE_IN_KB   = 4096
+  DEFINE FD_SIZE_IN_KB   = 2048
 !endif
 !endif
 !endif
@@ -157,12 +154,9 @@ [LibraryClasses]
   UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf
   
SerializeVariablesLib|OvmfPkg/Library/SerializeVariablesLib/SerializeVariablesLib.inf
   QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgDxeLib.inf
-  VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
   LoadLinuxLib|OvmfPkg/Library/LoadLinuxLib/LoadLinuxLib.inf
   
MemEncryptSevLib|OvmfPkg/Library/BaseMemEncryptSevLib/BaseMemEncryptSevLib.inf
-!if $(SMM_REQUIRE) == FALSE
   LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
-!endif
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
   
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
 
@@ -185,14 +179,8 @@ [LibraryClasses]
   OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
 !endif
 
-!if $(SECURE_BOOT_ENABLE) == TRUE
-  PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf
-  
TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
-  AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
-!else
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
   
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
-!endif
   VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
 
   TcpIoLib|MdeModulePkg/Library/DxeTcpIoLib/DxeTcpIoLib.inf
@@ -211,13 +199,7 @@ [LibraryClasses]
   
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
   XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
 
-!if $(TPM2_ENABLE) == TRUE
-  Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
-  
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLib.inf
-  
Tcg2PpVendorLib|SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf
-!else
   

[Xen-devel] [PATCH v2 07/31] OvmfPkg/XenResetVector: Saving start of day pointer for PVH guests

[Anthony PERARD]

As described in the Xen PVH documentation [1], "ebx: contains the
physical memory address where the loader has placed the boot start info
structure". To have this pointer saved to be able to use it later in the
PEI phase, we allocate some space in the MEMFD for it. We use 'XPVH' as
a signature (for "Xen PVH").

[1] https://xenbits.xenproject.org/docs/unstable/misc/pvh.html

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/OvmfPkg.dec | 4 
 OvmfPkg/XenOvmf.fdf | 4 
 OvmfPkg/XenResetVector/XenResetVector.inf   | 3 +++
 OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm  | 4 
 OvmfPkg/XenResetVector/XenResetVector.nasmb | 2 ++
 5 files changed, 17 insertions(+)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index e50c6179a2..1cbbc49a6b 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -127,6 +127,10 @@ [PcdsFixedAtBuild]
   gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize|0x0|UINT32|0x1a
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd|0x0|UINT32|0x1f
 
+  # Used by XenOvmf
+  gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtr|0x0|UINT32|0x30
+  gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtrSize|0x0|UINT32|0x31
+
 [PcdsDynamic, PcdsDynamicEx]
   gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index 20ebacd673..f9e58befd6 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -159,6 +159,10 @@ [FD.MEMFD]
 0x007000|0x001000
 
gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
 
+0x008000|0x001000
+# Used by XenResetVector to communicate with XenPlatformPei
+gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtr|gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtrSize
+
 0x01|0x01
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
 
diff --git a/OvmfPkg/XenResetVector/XenResetVector.inf 
b/OvmfPkg/XenResetVector/XenResetVector.inf
index 5c05f02285..ec98c17876 100644
--- a/OvmfPkg/XenResetVector/XenResetVector.inf
+++ b/OvmfPkg/XenResetVector/XenResetVector.inf
@@ -41,3 +41,6 @@ [BuildOptions]
 [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
+
+  gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtr
+  gUefiOvmfPkgTokenSpaceGuid.PcdXenStartOfDayStructPtrSize
diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm 
b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
index c4802bf4d1..4e55b0ac1f 100644
--- a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
+++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
@@ -22,6 +22,10 @@ xenPVHMain:
 ; ESP -  Initial value of the EAX register (BIST: Built-in Self Test)
 mov esp, eax
 
+;; Store "Start of day" struct pointer for later use
+mov dword[PVH_SPACE (0)], ebx
+mov dword[PVH_SPACE (4)], 'XPVH'
+
 cli
 
 mov ebx, ADDR_OF(gdtr)
diff --git a/OvmfPkg/XenResetVector/XenResetVector.nasmb 
b/OvmfPkg/XenResetVector/XenResetVector.nasmb
index d5a791c139..50cb81fcd1 100644
--- a/OvmfPkg/XenResetVector/XenResetVector.nasmb
+++ b/OvmfPkg/XenResetVector/XenResetVector.nasmb
@@ -41,6 +41,8 @@
 
 %include "CommonMacros.inc"
 
+%define PVH_SPACE(Offset) (FixedPcdGet32 (PcdXenStartOfDayStructPtr) + 
(Offset))
+
 %include "PostCodes.inc"
 
 %ifdef DEBUG_PORT80
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v2 03/31] OvmfPkg: Introduce XenResetVector

[Anthony PERARD]

Copy of OvmfPkg/ResetVector, with one changes:
  - SEC_DEFAULT_CR0: enable cache (bit 30 or CD set to 0)

Xen copies the OVMF code to RAM, there is no need to disable cache.

This new module will later be modified to add a new entry point, more
detail in a following commit "OvmfPkg/XenResetVector: Add new entry point
for Xen PVH"

Value FILE_GUID of XenResetVector have not changed compare to ResetVector
because it is a special value.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenOvmf.dsc
 | 2 +-
 OvmfPkg/XenOvmf.fdf
 | 2 +-
 OvmfPkg/{ResetVector/ResetVector.inf => XenResetVector/XenResetVector.inf} 
 | 5 +++--
 {UefiCpuPkg/ResetVector/Vtf0 => 
OvmfPkg/XenResetVector}/Ia16/Real16ToFlat32.asm | 4 +++-
 OvmfPkg/{ResetVector => XenResetVector}/Ia32/PageTables64.asm  
 | 2 ++
 OvmfPkg/{ResetVector/ResetVector.nasmb => XenResetVector/XenResetVector.nasmb} 
 | 2 ++
 6 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
index bfe9190735..6161133fa8 100644
--- a/OvmfPkg/XenOvmf.dsc
+++ b/OvmfPkg/XenOvmf.dsc
@@ -503,7 +503,7 @@ [PcdsDynamicDefault]
 #
 

 [Components]
-  OvmfPkg/ResetVector/ResetVector.inf
+  OvmfPkg/XenResetVector/XenResetVector.inf
 
   #
   # SEC Phase modules
diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index 612ffb2e01..292cf4b492 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -124,7 +124,7 @@ [FV.SECFV]
 #
 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/ResetVector/ResetVector.inf 
b/OvmfPkg/XenResetVector/XenResetVector.inf
similarity index 88%
copy from OvmfPkg/ResetVector/ResetVector.inf
copy to OvmfPkg/XenResetVector/XenResetVector.inf
index d1e5d4d9bd..5c05f02285 100644
--- a/OvmfPkg/ResetVector/ResetVector.inf
+++ b/OvmfPkg/XenResetVector/XenResetVector.inf
@@ -2,6 +2,7 @@
 #  Reset Vector
 #
 #  Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
+#  Copyright (c) 2019, Citrix Systems, Inc.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
@@ -14,7 +15,7 @@
 
 [Defines]
   INF_VERSION= 0x00010005
-  BASE_NAME  = ResetVector
+  BASE_NAME  = XenResetVector
   FILE_GUID  = 1BA0062E-C779-4582-8566-336AE8F78F09
   MODULE_TYPE= SEC
   VERSION_STRING = 1.1
@@ -26,7 +27,7 @@ [Defines]
 #
 
 [Sources]
-  ResetVector.nasmb
+  XenResetVector.nasmb
 
 [Packages]
   OvmfPkg/OvmfPkg.dec
diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm 
b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
similarity index 94%
copy from UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm
copy to OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
index bc68c8dd74..e22e92c8a6 100644
--- a/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm
+++ b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
@@ -3,6 +3,8 @@
 ; Transition from 16 bit real mode into 32 bit flat protected mode
 ;
 ; Copyright (c) 2008 - 2010, Intel Corporation. All rights reserved.
+; Copyright (c) 2019, Citrix Systems, Inc.
+;
 ; 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
@@ -13,7 +15,7 @@
 ;
 ;--
 
-%define SEC_DEFAULT_CR0  0x4023
+%define SEC_DEFAULT_CR0  0x0023
 %define SEC_DEFAULT_CR4  0x640
 
 BITS16
diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
b/OvmfPkg/XenResetVector/Ia32/PageTables64.asm
similarity index 95%
copy from OvmfPkg/ResetVector/Ia32/PageTables64.asm
copy to OvmfPkg/XenResetVector/Ia32/PageTables64.asm
index db1590aedd..ded466031b 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/XenResetVector/Ia32/PageTables64.asm
@@ -3,6 +3,8 @@
 ; Sets the CR3 register for 64-bit paging
 ;
 ; Copyright (c) 2008 - 2013, Intel Corporation. All rights reserved.
+; Copyright (c) 2019, Citrix Systems, Inc.
+;
 ; 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
diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb 
b/OvmfPkg/XenResetVector/XenResetVector.nasmb
similarity index 94%
copy from 

[Xen-devel] [PATCH v2 01/31] OvmfPkg/ResetSystemLib: Add missing dependency on PciLib

[Anthony PERARD]

and remove extra includes of OvmfPlatforms.h.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---

Notes:
v2:
- also add PciLib.h include to the .c
- and remove extra include of OvmfPlatforms.h

 OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf | 1 +
 OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c   | 3 +--
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf 
b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
index 39ca805730..ebd722e66b 100644
--- a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
+++ b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
@@ -36,4 +36,5 @@ [Packages]
 [LibraryClasses]
   DebugLib
   IoLib
+  PciLib
   TimerLib
diff --git a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c 
b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c
index cc75d046a8..9348502836 100644
--- a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c
+++ b/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.c
@@ -17,11 +17,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-#include 
-
 VOID
 AcpiPmControl (
   UINTN SuspendType
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v2 00/31] Specific platform to run OVMF in Xen PVH and HVM guests

[Anthony PERARD]

Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/ovmf.git br.platform-xen-pvh-v2

Hi,

I've started to create a Xen specific platform, in OvmfPkg/XenOvmf.dsc
with the goal to make it work on both Xen HVM and Xen PVH.

The first few patches only create the platform and duplicate some code from
OvmfPkg and the later patches makes OVMF boot in a Xen PVH guest and can boot
a Linux guest.

After this patch series, I'd like to wait a bit before removing Xen support
from the OvmfPkg*.dsc, to allow time to switch to the new Xen only platform,
maybe 1 year.

Question:

Should we start moving these to a different *Pkg? Like it's done for ArmPkg and
ArmVirtPkg?  Maybe XenPkg.

To build and boot:

To build, simply run OvmfPkg/build.sh -p OvmfPkg/XenOvmf.dsc
Then use OVMF.fd as a kernel of a pvh guest config file (with xl/libxl).

Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/ovmf.git br.platform-xen-pvh-v2

Anthony PERARD (31):
  OvmfPkg/ResetSystemLib: Add missing dependency on PciLib
  OvmfPkg: Create platform XenOvmf
  OvmfPkg: Introduce XenResetVector
  OvmfPkg: Introduce XenPlatformPei
  OvmfPkg/XenOvmf: Creating an ELF header
  OvmfPkg/XenResetVector: Add new entry point for Xen PVH
  OvmfPkg/XenResetVector: Saving start of day pointer for PVH guests
  OvmfPkg/XenResetVector: Allow to jumpstart from either hvmloader or
PVH
  OvmfPkg/XenOvmf: use a TimerLib instance that depends only on the CPU
  OvmfPkg/XenPlatformPei: Detect OVMF_INFO from hvmloader
  OvmfPkg/XenPlatformPei: Use mXenHvmloaderInfo to get E820
  OvmfPkg/XenPlatformPei: Grab RSDP from PVH guest start of day struct
  OvmfPkg/Library/XenPlatformLib: New library
  OvmfPkg/AcpiPlatformDxe: Use PVH RSDP if exist
  OvmfPkg/XenHypercallLib: Enable it in PEIM
  OvmfPkg/XenPlatformPei: Introduce XenHvmloaderDetected
  OvmfPkg/XenPlatformPei: Reserve hvmloader's memory only when it as
runned
  OvmfPkg/XenPlatformPei: Setup HyperPages earlier
  OvmfPkg/XenPlatformPei: Introduce XenPvhDetected
  OvmfPkg: Import XENMEM_memory_map hypercall to Xen/memory.h
  OvmfPkg/XenPlatformPei: Get E820 table via hypercall ...
  OvmfPkg/XenPlatformPei: Rework memory detection
  OvmfPkg/XenPlatformPei: Reserve VGA memory region, to boot Linux
  OvmfPkg/XenPlatformPei: Ignore missing PCI Host Bridge on Xen PVH
  OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen
PVH
  OvmfPkg/XenOvmf: Override PcdFSBClock to Xen vLAPIC timer frequency
  OvmfPkg/XenOvmf: Introduce XenTimerDxe
  OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn
  OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables
  OvmfPkg: Move XenRealTimeClockLib from ArmVirtPkg
  OvmfPkg/XenOvmf: use RealTimeClockRuntimeDxe from EmbeddedPkg

 OvmfPkg/OvmfPkg.dec
 |   4 +
 ArmVirtPkg/ArmVirtXen.dsc  
 |   2 +-
 OvmfPkg/OvmfPkgIa32.dsc
 |   1 +
 OvmfPkg/OvmfPkgIa32X64.dsc 
 |   1 +
 OvmfPkg/OvmfPkgX64.dsc 
 |   1 +
 OvmfPkg/{OvmfPkgX64.dsc => XenOvmf.dsc}
 | 236 ++--
 OvmfPkg/XenOvmf.fdf
 | 561 
 OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
 |   2 +-
 OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf  
 |   4 +
 OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf  
 |   1 +
 OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
 |   2 +-
 ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf => 
OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf |  30 +-
 {ArmVirtPkg => OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
 |   0
 OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
 |  35 ++
 OvmfPkg/XenPlatformPei/XenPlatformPei.inf  
 | 107 
 OvmfPkg/XenResetVector/XenResetVector.inf  
 |  46 ++
 OvmfPkg/XenTimerDxe/XenTimerDxe.inf
 |  49 ++
 

[Xen-devel] [PATCH v2 05/31] OvmfPkg/XenOvmf: Creating an ELF header

[Anthony PERARD]

This header replace the embedded variable store.

The ELF header explain to a loader to load the binary at the address
1MB, then jump to the PVH entry point which will be created in a later
patch.

That patch include generate_elf_header.c which can be use to regenerate
the ELF header, but this will be a manual step.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Anthony PERARD 
---

Notes:
This "ELF header" might not be the best way, but with it the Xen
toolstack can load OVMF like any other PVH-compatible kernel without
modification. Is there a better way?

The generate_elf_header.c file was used to generate the series of hex
number. It isn't at a right place but I'm not sure where to put this C
file. Maybe in the commit message or maybe it could be forgotten since
I've added all the comments in the .fdf file.

 OvmfPkg/XenOvmf.fdf   | 82 +++-
 generate_elf_header.c | 78 +++
 2 files changed, 157 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
index 295e30ca3f..20ebacd673 100644
--- a/OvmfPkg/XenOvmf.fdf
+++ b/OvmfPkg/XenOvmf.fdf
@@ -21,8 +21,8 @@ [Defines]
 !include OvmfPkg.fdf.inc
 
 #
-# Build the variable store and the firmware code as one unified flash device
-# image.
+# This will allow the flash device image to be recognize as an ELF, with first
+# an ELF headers, then the firmware code.
 #
 [FD.OVMF]
 BaseAddress   = $(FW_BASE_ADDRESS)
@@ -31,7 +31,83 @@ [FD.OVMF]
 BlockSize = $(BLOCK_SIZE)
 NumBlocks = $(FW_BLOCKS)
 
-!include VarStore.fdf.inc
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0x|0xe000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x|0x0004
+!endif
+#was NV_VARIABLE_STORE
+DATA = {
+  # ELF file header
+  0x7f, 0x45, 0x4c, 0x46, # e_ident[0..3]: Magic number
+  0x01, # File class: 32-bit objects
+  0x01, # Data encoding: 2's complement, little endian
+  0x01, # File version
+  0x03, # OS ABI identification: Object uses GNU ELF extensions
+  0x00, # ABI version
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  # e_ident[EI_PAD...]
+
+  0x02, 0x00, # e_type = Executable file
+  0x03, 0x00, # e_machine = Intel 80386
+  0x01, 0x00, 0x00, 0x00, # e_version
+  0xd0, 0xff, 0x2f, 0x00, # e_entry: Entry point virtual address
+  0x34, 0x00, 0x00, 0x00, # e_phoff: Program header table file offset
+  0x00, 0x00, 0x00, 0x00, # e_shoff: Section header table file offset
+  0x00, 0x00, 0x00, 0x00, # e_flags: Processor-specific flags
+  0x34, 0x00, #e_ehsize: ELF header size
+  0x20, 0x00, # e_phentsize: Program header table entry size
+  0x01, 0x00, # e_phnum: Program header table entry count
+  0x00, 0x00, # e_shentsize: Section header table entry size
+  0x00, 0x00, # e_shnum: Section header table entry count
+  0xff, 0xff, # e_shstrndx
+
+  # ELF Program segment header
+  0x01, 0x00, 0x00, 0x00, # p_type = Loadable program segment
+  0x00, 0x00, 0x00, 0x00, # p_offset
+  0x00, 0x00, 0x10, 0x00, # p_vaddr: Segment virtual address
+  0x00, 0x00, 0x10, 0x00, # p_paddr: Segment physical address
+  0x00, 0x00, 0x20, 0x00, # p_filesz: Segment size in file
+  0x00, 0x00, 0x20, 0x00, # p_memsz: Segment size in memory
+  0x07, 0x00, 0x00, 0x00, # p_flags = Segment is executable | writable | 
readable
+  0x00, 0x00, 0x00, 0x00  # p_align
+
+}
+
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0xe000|0x1000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x0004|0x1000
+!endif
+#NV_EVENT_LOG
+
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0xf000|0x1000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x00041000|0x1000
+!endif
+#NV_FTW_WORKING
+DATA = {
+  # EFI_FAULT_TOLERANT_WORKING_BLOCK_HEADER->Signature = 
gEdkiiWorkingBlockSignatureGuid =
+  #  { 0x9e58292b, 0x7c68, 0x497d, { 0xa0, 0xce, 0x65,  0x0, 0xfd, 0x9f, 0x1b, 
0x95 }}
+  0x2b, 0x29, 0x58, 0x9e, 0x68, 0x7c, 0x7d, 0x49,
+  0xa0, 0xce, 0x65,  0x0, 0xfd, 0x9f, 0x1b, 0x95,
+  # Crc:UINT32#WorkingBlockValid:1, WorkingBlockInvalid:1, Reserved
+  0x2c, 0xaf, 0x2c, 0x64, 0xFE, 0xFF, 0xFF, 0xFF,
+  # WriteQueueSize: UINT64
+  0xE0, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
+}
+
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0x0001|0x0001
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x00042000|0x00042000
+!endif
+#NV_FTW_SPARE
+
 
 $(VARS_SIZE)|$(FVMAIN_SIZE)
 FV = FVMAIN_COMPACT
diff --git a/generate_elf_header.c b/generate_elf_header.c
new file mode 100644
index 00..5bb87df0d6
--- /dev/null
+++ b/generate_elf_header.c
@@ -0,0 +1,78 @@
+#include "elf.h"
+#include "stdio.h"
+#include "stddef.h"
+
+/*
+ * TODO:
+ *   this header will need a XEN_ELFNOTE_PHYS32_ENTRY
+ *   right now, it works without, but that might change.
+ */
+
+void print_hdr(void *s, size_t size) {
+  char *c = s;
+
+  while (size--) {
+printf("0x%02hhx, ", *(c++));
+  }
+}
+int main(void){
+  // FW_SIZE
+  size_t 

Re: [Xen-devel] [PATCH 3/3] memory: restrict XENMEM_remove_from_physmap to translated guests

[Jan Beulich]

>>> On 08.04.19 at 13:58,  wrote:
> On 3/5/19 1:28 PM, Jan Beulich wrote:
>> @@ -298,7 +298,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_add_to_physm
>>   
>>   /*
>>* Unmaps the page appearing at a particular GPFN from the specified 
>> guest's
>> - * pseudophysical address space.
>> + * physical address space (translated guests only).
> 
> While you modify the comment, can you replace GPFN with GFN?

I did consider this when writing the patch, but then this would
bring it out of sync with the structure field and its associated
comment. Plus the "add" side comment would then want
changing too. And public/memory.h has quite a few more uses
of GPFN / gpfn.

To be honest I'd prefer to leave this as is right here, for it to get
cleaned up in one go.

> Other than that:
> 
> Reviewed-by: Julien Grall 

Thanks, but as per above I'm not sure whether to actually apply
it.

Jan



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

Re: [Xen-devel] [PATCH v2] xen/timers: Fix memory leak with cpu unplug/plug

[Julien Grall]

Hi Andrew,

On 4/8/19 1:09 PM, Andrew Cooper wrote:

On 08/04/2019 12:38, Julien Grall wrote:

Hi,

On 4/8/19 11:47 AM, Andrew Cooper wrote:

On 08/04/2019 11:39, Julien Grall wrote:

Hi,

On 4/8/19 10:39 AM, Andrew Cooper wrote:

+    case CPU_RESUME_FAILED:
+    if ( !park_offline_cpus && system_state !=
SYS_STATE_suspend )


This patch breaks compilation on arm32/arm64 because park_offline_cpus
is not defined:

timer.c: In function 'cpu_callback':
timer.c:651:15: error: 'park_offline_cpus' undeclared (first use in
this function)
   if ( !park_offline_cpus && system_state !=
SYS_STATE_suspend )
     ^

What is the purpose of park_offline_cpus?


Sorry.  I should have waited for a full build test first.

park_offline_cpus is a workaround for Intel's MCE behaviour, where the
system will shut down rather than deliver an #MC if machine checking
isn't configured on all CPUs.

As a result, we have to start all CPUs, even beyond maxcpus= and set up
machine check handling, and never ever free their stacks, even if we'd
prefer the CPUs to be offline.


I am a bit confused, why this is necessary now for the timer and not
in other places of the common code?



Are you happy with a

#define park_offline_cpus false >
in ARM?


The name is fairly confusing if you don't know the background.

But I have to admit that even with your explanation above, I still
don't understand why you need to check park_offline_cpus in the timers.


It is all to do with how/when we free per-cpu data.

Technically speaking (with the memory leak fixed) the old arrangement
ought to function correctly, but the new arrangement is more efficient.

Where would the free happen in the "less efficient" way?

Cheers,

--
Julien Grall

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

[Xen-devel] [linux-next test] 134429: trouble: blocked/broken/fail/pass

[osstest service owner]

flight 134429 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134429/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-xsm  broken
 build-arm64-pvopsbroken

Tests which did not succeed, but are not blocking:
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 4 host-install(4) broken like 134286
 build-arm64   4 host-install(4) broken like 134286
 build-arm64-xsm   4 host-install(4) broken like 134286
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail like 134286
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail like 
134286
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 134286
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 134286
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 134286
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 134286
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 134286
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 134286
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 134286
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 134286
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 134286
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux81e0cd6a7f096b96428dfec5735c90432ae89271
baseline version:
 linux5e7a8ca319268a70a6c7c3c1fde5bea38e1e5539

Last test of basis  (not found) 
Failing since   (not found) 
Testing 

Re: [Xen-devel] [PATCH] gitlab-ci: use git clean -ffdx in build each commit test

[Wei Liu]

On Mon, Apr 08, 2019 at 01:45:15PM +0100, Wei Liu wrote:
> On Mon, Apr 08, 2019 at 01:43:57PM +0100, Anthony PERARD wrote:
> > On Mon, Apr 08, 2019 at 12:50:31PM +0100, Wei Liu wrote:
> > > The build script invoked is designed to run in a pristine checkout.
> > > 
> > > Signed-off-by: Wei Liu 
> > > ---
> > >  automation/gitlab-ci/build-each-commit.sh | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/automation/gitlab-ci/build-each-commit.sh 
> > > b/automation/gitlab-ci/build-each-commit.sh
> > > index 275bc71902..879028b5a7 100755
> > > --- a/automation/gitlab-ci/build-each-commit.sh
> > > +++ b/automation/gitlab-ci/build-each-commit.sh
> > > @@ -15,4 +15,4 @@ fi
> > >  echo "Building ${CI_COMMIT_BEFORE_SHA}..${CI_COMMIT_SHA}"
> > >  
> > >  NON_SYMBOLIC_REF=1 ./automation/scripts/build-test.sh 
> > > ${CI_COMMIT_BEFORE_SHA} ${CI_COMMIT_SHA} \
> > > -bash -c "make -j4 distclean && ./automation/scripts/build"
> > > +bash -c "git clean -ffdx && ./automation/scripts/build"
> > 
> > Is this mean that QEMU, OVMF, SeaBIOS, ... are going to be clonned again
> > and again? But maybe it doesn't matter.
> 
> Yes. But I don't think that matters much.

BTW, distclean deletes those repositories as well. The nature of this
specific test means it is best to start in a pristine environment,
because we could potentially move the HEAD of all those repositories.

Wei.

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

Re: [Xen-devel] [PATCH] gitlab-ci: use git clean -ffdx in build each commit test

[Wei Liu]

On Mon, Apr 08, 2019 at 01:43:57PM +0100, Anthony PERARD wrote:
> On Mon, Apr 08, 2019 at 12:50:31PM +0100, Wei Liu wrote:
> > The build script invoked is designed to run in a pristine checkout.
> > 
> > Signed-off-by: Wei Liu 
> > ---
> >  automation/gitlab-ci/build-each-commit.sh | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/automation/gitlab-ci/build-each-commit.sh 
> > b/automation/gitlab-ci/build-each-commit.sh
> > index 275bc71902..879028b5a7 100755
> > --- a/automation/gitlab-ci/build-each-commit.sh
> > +++ b/automation/gitlab-ci/build-each-commit.sh
> > @@ -15,4 +15,4 @@ fi
> >  echo "Building ${CI_COMMIT_BEFORE_SHA}..${CI_COMMIT_SHA}"
> >  
> >  NON_SYMBOLIC_REF=1 ./automation/scripts/build-test.sh 
> > ${CI_COMMIT_BEFORE_SHA} ${CI_COMMIT_SHA} \
> > -bash -c "make -j4 distclean && ./automation/scripts/build"
> > +bash -c "git clean -ffdx && ./automation/scripts/build"
> 
> Is this mean that QEMU, OVMF, SeaBIOS, ... are going to be clonned again
> and again? But maybe it doesn't matter.

Yes. But I don't think that matters much.

Wei.

> 
> -- 
> Anthony PERARD

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

Re: [Xen-devel] [PATCH] x86/shadow: Drop incorrect diagnostic when shadowing TSS.RSP0

[Andrew Cooper]

On 08/04/2019 13:11, Jan Beulich wrote:
 On 08.04.19 at 13:37,  wrote:
>> On 08/04/2019 11:14, Jan Beulich wrote:
>> On 05.04.19 at 21:09,  wrote:
 --- a/xen/arch/x86/mm/shadow/multi.c
 +++ b/xen/arch/x86/mm/shadow/multi.c
 @@ -3305,8 +3305,9 @@ static int sh_page_fault(struct vcpu *v,
  {
  /*
   * If we are in the middle of injecting an exception or interrupt 
 then
 - * we should not emulate: it is not the instruction at %eip that 
 caused
 - * the fault. Furthermore it is almost certainly the case the 
 handler
 + * we should not emulate: the fault is a side effect of the 
 processor
 + * trying to push an exception frame onto a stack which has yet 
 to be
 + * shadowed.  Furthermore it is almost certainly the case the 
 handler
   * stack is currently considered to be a page table, so we should
   * unshadow the faulting page before exiting.
   */
>>> Your addition to me looks to contradict the part of the comment you
>>> leave in place: You say "which has yet to be shadowed", while the
>>> pre-existing text says "it is almost certainly the case the handler
>>> stack is currently considered to be a page table", which to me means
>>> it _is_ already shadowed (and in fact should not be).
>>>
>>> In your addition, do you perhaps mean the page tables covering the
>>> stack which have yet to be shadowed?
>> This clause is inside an hvm_event_pending() which looks at VMCS/VMCB
>> pending injection.
>>
>> This only becomes true via VT-x's
>>
>> __vmread(IDT_VECTORING_INFO, _info);
>> if ( exit_reason != EXIT_REASON_TASK_SWITCH )
>> vmx_idtv_reinject(idtv_info);
>>
>> path, and the equivalent case on SVM which leaves the EVENTINJ field
>> valid after vmexit.  (This is assuming that we have no bugs whereby we
>> enter sh_page_fault() late, after some emulation has occurred.)
>>
>> What this means is that the processor is trying to deliver an exception,
>> and the #PF intercept has been hit (which occurs before escalation to
>> #DF).  i.e. it is the memory reads/writes made by microcode which suffer
>> a fault due to the linear addresses not being present in the shadows.
>>
>> Beyond that, there is a second aspect to getting here, which is when the
>> linear address hit something which the shadow code thinks is protected,
>> which AFAICT, starts off as everything which doesn't have an L1 shadow
>> pointing writeably at it.
>>
>> In the XTF case where I encountered this first, it so happens that the
>> processor delivering an exception from userspace is the first thing to
>> ever touch the linear address at RSP0, so the stack always becomes
>> shadowed during IDT vectoring.
> I'm (at least) mildly confused: I follow what you write (I think), but
> you again say "the stack always becomes shadowed". My original
> question was whether you really mean that, as stacks, if at all,
> should get shadowed only unintentionally (and hence get un-shadowed
> immediately when that condition is detected). That is, my (slightly
> rephrased) question stands: Do you perhaps mean the page tables
> mapping the stack to become shadowed, rather than the stack itself?

I guess this is an issue of terminology, to which I defer to Tim to judge.

But yes - I mean is "the linear address mapping RSP0 getting entered
into the shadow pagetables".

~Andrew

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

[Xen-devel] [linux-4.4 test] 134482: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 134482 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134482/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-xsm  broken
 build-arm64-pvopsbroken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 133468
 build-arm64-pvops 4 host-install(4)broken REGR. vs. 133468
 build-arm64   4 host-install(4)broken REGR. vs. 133468
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 133468

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-multivcpu 12 guest-start fail in 134396 pass in 134482
 test-amd64-i386-xl-xsm   12 guest-start  fail in 134396 pass in 134482
 test-amd64-amd64-xl-rtds 12 guest-start  fail in 134396 pass in 134482
 test-amd64-amd64-libvirt 12 guest-start  fail in 134396 pass in 134482
 test-amd64-amd64-pair  21 guest-start/debian fail in 134396 pass in 134482
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16 
guest-start/debianhvm.repeat fail in 134396 pass in 134482
 test-amd64-i386-pair   21 guest-start/debian fail in 134396 pass in 134482
 test-amd64-amd64-examine  4 memdisk-try-append fail pass in 134396
 test-armhf-armhf-libvirt 16 guest-start/debian.repeat  fail pass in 134396

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   

Re: [Xen-devel] [PATCH] x86/shadow: Drop incorrect diagnostic when shadowing TSS.RSP0

[Jan Beulich]

>>> On 08.04.19 at 13:37,  wrote:
> On 08/04/2019 11:14, Jan Beulich wrote:
> On 05.04.19 at 21:09,  wrote:
>>> --- a/xen/arch/x86/mm/shadow/multi.c
>>> +++ b/xen/arch/x86/mm/shadow/multi.c
>>> @@ -3305,8 +3305,9 @@ static int sh_page_fault(struct vcpu *v,
>>>  {
>>>  /*
>>>   * If we are in the middle of injecting an exception or interrupt 
>>> then
>>> - * we should not emulate: it is not the instruction at %eip that 
>>> caused
>>> - * the fault. Furthermore it is almost certainly the case the 
>>> handler
>>> + * we should not emulate: the fault is a side effect of the 
>>> processor
>>> + * trying to push an exception frame onto a stack which has yet to 
>>> be
>>> + * shadowed.  Furthermore it is almost certainly the case the 
>>> handler
>>>   * stack is currently considered to be a page table, so we should
>>>   * unshadow the faulting page before exiting.
>>>   */
>> Your addition to me looks to contradict the part of the comment you
>> leave in place: You say "which has yet to be shadowed", while the
>> pre-existing text says "it is almost certainly the case the handler
>> stack is currently considered to be a page table", which to me means
>> it _is_ already shadowed (and in fact should not be).
>>
>> In your addition, do you perhaps mean the page tables covering the
>> stack which have yet to be shadowed?
> 
> This clause is inside an hvm_event_pending() which looks at VMCS/VMCB
> pending injection.
> 
> This only becomes true via VT-x's
> 
> __vmread(IDT_VECTORING_INFO, _info);
> if ( exit_reason != EXIT_REASON_TASK_SWITCH )
> vmx_idtv_reinject(idtv_info);
> 
> path, and the equivalent case on SVM which leaves the EVENTINJ field
> valid after vmexit.  (This is assuming that we have no bugs whereby we
> enter sh_page_fault() late, after some emulation has occurred.)
> 
> What this means is that the processor is trying to deliver an exception,
> and the #PF intercept has been hit (which occurs before escalation to
> #DF).  i.e. it is the memory reads/writes made by microcode which suffer
> a fault due to the linear addresses not being present in the shadows.
> 
> Beyond that, there is a second aspect to getting here, which is when the
> linear address hit something which the shadow code thinks is protected,
> which AFAICT, starts off as everything which doesn't have an L1 shadow
> pointing writeably at it.
> 
> In the XTF case where I encountered this first, it so happens that the
> processor delivering an exception from userspace is the first thing to
> ever touch the linear address at RSP0, so the stack always becomes
> shadowed during IDT vectoring.

I'm (at least) mildly confused: I follow what you write (I think), but
you again say "the stack always becomes shadowed". My original
question was whether you really mean that, as stacks, if at all,
should get shadowed only unintentionally (and hence get un-shadowed
immediately when that condition is detected). That is, my (slightly
rephrased) question stands: Do you perhaps mean the page tables
mapping the stack to become shadowed, rather than the stack itself?

Jan



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

Re: [Xen-devel] [PATCH v2] xen/timers: Fix memory leak with cpu unplug/plug

[Andrew Cooper]

On 08/04/2019 12:38, Julien Grall wrote:
> Hi,
>
> On 4/8/19 11:47 AM, Andrew Cooper wrote:
>> On 08/04/2019 11:39, Julien Grall wrote:
>>> Hi,
>>>
>>> On 4/8/19 10:39 AM, Andrew Cooper wrote:
 +    case CPU_RESUME_FAILED:
 +    if ( !park_offline_cpus && system_state !=
 SYS_STATE_suspend )
>>>
>>> This patch breaks compilation on arm32/arm64 because park_offline_cpus
>>> is not defined:
>>>
>>> timer.c: In function 'cpu_callback':
>>> timer.c:651:15: error: 'park_offline_cpus' undeclared (first use in
>>> this function)
>>>   if ( !park_offline_cpus && system_state !=
>>> SYS_STATE_suspend )
>>>     ^
>>>
>>> What is the purpose of park_offline_cpus?
>>
>> Sorry.  I should have waited for a full build test first.
>>
>> park_offline_cpus is a workaround for Intel's MCE behaviour, where the
>> system will shut down rather than deliver an #MC if machine checking
>> isn't configured on all CPUs.
>>
>> As a result, we have to start all CPUs, even beyond maxcpus= and set up
>> machine check handling, and never ever free their stacks, even if we'd
>> prefer the CPUs to be offline.
>
> I am a bit confused, why this is necessary now for the timer and not
> in other places of the common code?
>
>>
>> Are you happy with a
>>
>> #define park_offline_cpus false >
>> in ARM?
>
> The name is fairly confusing if you don't know the background.
>
> But I have to admit that even with your explanation above, I still
> don't understand why you need to check park_offline_cpus in the timers.

It is all to do with how/when we free per-cpu data.

Technically speaking (with the memory leak fixed) the old arrangement
ought to function correctly, but the new arrangement is more efficient.

~Andrew

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

Re: [Xen-devel] [PATCH] xen/arm: p2m: configure pa_range_info table to support 42 bit PA systems.

[Julien Grall]

Hi,

On 3/15/19 11:57 PM, Feng Kan OS wrote:

Thanks Julien.

On 3/15/19 4:21 AM, Julien Grall wrote:

Hi,

Thank you for posting the patch.

Title: No need for full stop in the commit title.

On 15/03/2019 08:34, Vishnu Pajjuri OS wrote:
I can't remember which other platforms support 42-bits PA. I think at
that time it was X-Gene. As long as no current embedded platform we
support use 42-bit PA, this change may be ok. Stefano do you recall what
was the platform?

Ampere eMAG platform is essentially the continuation of X-Gene. These
systems are targeted as servers with upto 1TB of RAM.


In any case, the new behavior (and consequence) needs to be clearly
explained in the commit message.

Got it, we will resubmit if Stefano is okay with the change.


To make progress on this patch, I would suggest to resubmit it with the 
changes requested.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 3/3] memory: restrict XENMEM_remove_from_physmap to translated guests

[Julien Grall]

Hi Jan,

On 3/5/19 1:28 PM, Jan Beulich wrote:

@@ -298,7 +298,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_add_to_physm
  
  /*

   * Unmaps the page appearing at a particular GPFN from the specified guest's
- * pseudophysical address space.
+ * physical address space (translated guests only).


While you modify the comment, can you replace GPFN with GFN?

Other than that:

Reviewed-by: Julien Grall 

Cheer,s

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2] docs/xl: Clarify documentation for mem-max and mem-set

[Juergen Gross]

On 08/04/2019 13:09, George Dunlap wrote:
> mem-set is the primary command that users will need to use and
> understand.  Move it first, and clarify the wording; also specify that
> you can't set the target higher than maxmem from the domain config.
> 
> mem-max is actually a pretty useless command at the moment.  Clarify
> that users are not expected to use it; and document all of its quirky
> behavior.
> 
> Signed-off-by: George Dunlap 
> ---
> v2:
> - Reword memory unit section based on review feedback
> 
> I'm actully somewhat tempted to take out the entry for mem-max
> entirely -- it's not at all clear to me what anyone would use it for,
> and it's only likely to confuse people.

It is needed for being able to hotplug memory to a domain.

You'll need to:

- raise the limit of the domain via xl mem-max
- modify the static-max xenstore entry
- trigger hotplug in the domain (e.g. via ACPI in HVM)

Making the interface more usable is on my agenda for quite a while now,
but I have been too busy with other stuff lately.


Juergen

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

[Xen-devel] [PATCH] gitlab-ci: use git clean -ffdx in build each commit test

[Wei Liu]

The build script invoked is designed to run in a pristine checkout.

Signed-off-by: Wei Liu 
---
 automation/gitlab-ci/build-each-commit.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/automation/gitlab-ci/build-each-commit.sh 
b/automation/gitlab-ci/build-each-commit.sh
index 275bc71902..879028b5a7 100755
--- a/automation/gitlab-ci/build-each-commit.sh
+++ b/automation/gitlab-ci/build-each-commit.sh
@@ -15,4 +15,4 @@ fi
 echo "Building ${CI_COMMIT_BEFORE_SHA}..${CI_COMMIT_SHA}"
 
 NON_SYMBOLIC_REF=1 ./automation/scripts/build-test.sh ${CI_COMMIT_BEFORE_SHA} 
${CI_COMMIT_SHA} \
-bash -c "make -j4 distclean && ./automation/scripts/build"
+bash -c "git clean -ffdx && ./automation/scripts/build"
-- 
2.20.1


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

Re: [Xen-devel] [PATCH 3/3] memory: restrict XENMEM_remove_from_physmap to translated guests

[Julien Grall]

Hi Jan,

On 4/2/19 5:10 PM, Jan Beulich wrote:

On 02.04.19 at 12:26,  wrote:

On 05/03/2019 13:28, Jan Beulich wrote:

The commit re-introducing it (14eb3b41d0 ["xen: reinstate previously
unused XENMEM_remove_from_physmap hypercall"]) as well as the one having
originally introduced it (d818f3cb7c ["hvm: Use main memory for video
memory"]) and the one then purging it again (78c3097e4f ["Remove unused
XENMEM_remove_from_physmap"]) make clear that this operation is intended
for use on HVM (i.e. translated) guests only. Restrict it at least as
much, because for PV guests documentation (in the public header) does
not even match the implementation: It talks about GPFN as input, but
get_page_from_gfn() assumes a GMFN in the non-translated case (and hands
back the value passed in).

Also lift the check in XENMEM_add_to_physmap{,_batch} handling up
directly into top level hypercall handling, and clarify things in the
public header accordingly.

Take the liberty and also replace a pointless use of "current" with a
more efficient use of an existing local variable (or function parameter
to be precise).

Signed-off-by: Jan Beulich 
---
TBD: It could be further restricted, disallowing its use by a HVM guest
   on itself.


By HVM guest, do you refer to any auto-translated guest?


Yes - sorry for using an x86 term.


The interface XENME_remove_from_physmap is used by Arm to remove foreign
mappings from its p2m. There are potentially other space with similar case
(e.g grant-table...).


Oh, I see - this option goes away then.


TBD: Is using P2M_ALLOC here really appropriate? It means e.g.
   pointlessly populating a PoD slot just to unpopulate it again right
   away, with the page then free floating, i.e. no longer available
   for use to replace another PoD slot, and (afaict) no longer
   accessible by the guest in any way.
TBD: Is using guest_physmap_remove_page() here really appropriate? It
   means that e.g. MMIO pages wouldn't be removed. Going through
   guest_remove_page() (while skipping the de-allocation step) would
   seem more appropriate to me, which would address the P2M_ALLOC
   aspect above as well.


How is that an issue? Does XENMEM_add_to_physmap allows you to map MMIO
pages?


Well, there's XENMAPSPACE_dev_mmio which xatp handles. But
perhaps the MMIO example is more confusing than helpful. The
question really just is whether guest_remove_page() shouldn't
be used here instead of guest_physmap_remove_page()
de-allocation step aside, I am not really convinced you can reuse 
guest_remove_page() here. On x86, the function will not work on certain 
p2m types. Is it what we really want?




But of course - first of all I'd like to get acks (or feedback what to
change) on the actual patch here. The further points would all, if
anything, result in independent patches.


Make sense. I will have a look at the patch.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] x86/shadow: Drop incorrect diagnostic when shadowing TSS.RSP0

[Andrew Cooper]

On 08/04/2019 11:14, Jan Beulich wrote:
 On 05.04.19 at 21:09,  wrote:
>> --- a/xen/arch/x86/mm/shadow/multi.c
>> +++ b/xen/arch/x86/mm/shadow/multi.c
>> @@ -3305,8 +3305,9 @@ static int sh_page_fault(struct vcpu *v,
>>  {
>>  /*
>>   * If we are in the middle of injecting an exception or interrupt 
>> then
>> - * we should not emulate: it is not the instruction at %eip that 
>> caused
>> - * the fault. Furthermore it is almost certainly the case the 
>> handler
>> + * we should not emulate: the fault is a side effect of the 
>> processor
>> + * trying to push an exception frame onto a stack which has yet to 
>> be
>> + * shadowed.  Furthermore it is almost certainly the case the 
>> handler
>>   * stack is currently considered to be a page table, so we should
>>   * unshadow the faulting page before exiting.
>>   */
> Your addition to me looks to contradict the part of the comment you
> leave in place: You say "which has yet to be shadowed", while the
> pre-existing text says "it is almost certainly the case the handler
> stack is currently considered to be a page table", which to me means
> it _is_ already shadowed (and in fact should not be).
>
> In your addition, do you perhaps mean the page tables covering the
> stack which have yet to be shadowed?

This clause is inside an hvm_event_pending() which looks at VMCS/VMCB
pending injection.

This only becomes true via VT-x's

    __vmread(IDT_VECTORING_INFO, _info);
    if ( exit_reason != EXIT_REASON_TASK_SWITCH )
    vmx_idtv_reinject(idtv_info);

path, and the equivalent case on SVM which leaves the EVENTINJ field
valid after vmexit.  (This is assuming that we have no bugs whereby we
enter sh_page_fault() late, after some emulation has occurred.)

What this means is that the processor is trying to deliver an exception,
and the #PF intercept has been hit (which occurs before escalation to
#DF).  i.e. it is the memory reads/writes made by microcode which suffer
a fault due to the linear addresses not being present in the shadows.

Beyond that, there is a second aspect to getting here, which is when the
linear address hit something which the shadow code thinks is protected,
which AFAICT, starts off as everything which doesn't have an L1 shadow
pointing writeably at it.

In the XTF case where I encountered this first, it so happens that the
processor delivering an exception from userspace is the first thing to
ever touch the linear address at RSP0, so the stack always becomes
shadowed during IDT vectoring.

~Andrew

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

Re: [Xen-devel] [PATCH v2] xen/timers: Fix memory leak with cpu unplug/plug

[Julien Grall]

Hi,

On 4/8/19 11:47 AM, Andrew Cooper wrote:

On 08/04/2019 11:39, Julien Grall wrote:

Hi,

On 4/8/19 10:39 AM, Andrew Cooper wrote:

+    case CPU_RESUME_FAILED:
+    if ( !park_offline_cpus && system_state != SYS_STATE_suspend )


This patch breaks compilation on arm32/arm64 because park_offline_cpus
is not defined:

timer.c: In function 'cpu_callback':
timer.c:651:15: error: 'park_offline_cpus' undeclared (first use in
this function)
  if ( !park_offline_cpus && system_state != SYS_STATE_suspend )
    ^

What is the purpose of park_offline_cpus?


Sorry.  I should have waited for a full build test first.

park_offline_cpus is a workaround for Intel's MCE behaviour, where the
system will shut down rather than deliver an #MC if machine checking
isn't configured on all CPUs.

As a result, we have to start all CPUs, even beyond maxcpus= and set up
machine check handling, and never ever free their stacks, even if we'd
prefer the CPUs to be offline.


I am a bit confused, why this is necessary now for the timer and not in 
other places of the common code?




Are you happy with a

#define park_offline_cpus false >
in ARM?


The name is fairly confusing if you don't know the background.

But I have to admit that even with your explanation above, I still don't 
understand why you need to check park_offline_cpus in the timers.


Cheers,

--
Julien Grall

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

[Xen-devel] [PATCH] AMD/IOMMU: disable previously enabled IOMMUs upon init failure

[Jan Beulich]

If any IOMMUs were successfully initialized before encountering failure,
the successfully enabled ones should be disabled again before cleaning
up their resources.

Move disable_iommu() next to enable_iommu() to avoid a forward
declaration, and take the opportunity to remove stray blank lines ahead
of both functions' final closing braces.

Signed-off-by: Jan Beulich 

--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -909,7 +909,35 @@ static void enable_iommu(struct amd_iomm
 
 iommu->enabled = 1;
 spin_unlock_irqrestore(>lock, flags);
+}
+
+static void disable_iommu(struct amd_iommu *iommu)
+{
+unsigned long flags;
+
+spin_lock_irqsave(>lock, flags);
+
+if ( !iommu->enabled )
+{
+spin_unlock_irqrestore(>lock, flags);
+return;
+}
+
+amd_iommu_msi_enable(iommu, IOMMU_CONTROL_DISABLED);
+set_iommu_command_buffer_control(iommu, IOMMU_CONTROL_DISABLED);
+set_iommu_event_log_control(iommu, IOMMU_CONTROL_DISABLED);
+
+if ( amd_iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
+set_iommu_ppr_log_control(iommu, IOMMU_CONTROL_DISABLED);
+
+if ( amd_iommu_has_feature(iommu, IOMMU_EXT_FEATURE_GTSUP_SHIFT) )
+set_iommu_guest_translation_control(iommu, IOMMU_CONTROL_DISABLED);
+
+set_iommu_translation_control(iommu, IOMMU_CONTROL_DISABLED);
 
+iommu->enabled = 0;
+
+spin_unlock_irqrestore(>lock, flags);
 }
 
 static void __init deallocate_buffer(void *buf, uint32_t sz)
@@ -1046,6 +1074,7 @@ static void __init amd_iommu_init_cleanu
 list_del(>list);
 if ( iommu->enabled )
 {
+disable_iommu(iommu);
 deallocate_ring_buffer(>cmd_buffer);
 deallocate_ring_buffer(>event_log);
 deallocate_ring_buffer(>ppr_log);
@@ -1297,36 +1326,6 @@ error_out:
 return rc;
 }
 
-static void disable_iommu(struct amd_iommu *iommu)
-{
-unsigned long flags;
-
-spin_lock_irqsave(>lock, flags);
-
-if ( !iommu->enabled )
-{
-spin_unlock_irqrestore(>lock, flags); 
-return;
-}
-
-amd_iommu_msi_enable(iommu, IOMMU_CONTROL_DISABLED);
-set_iommu_command_buffer_control(iommu, IOMMU_CONTROL_DISABLED);
-set_iommu_event_log_control(iommu, IOMMU_CONTROL_DISABLED);
-
-if ( amd_iommu_has_feature(iommu, IOMMU_EXT_FEATURE_PPRSUP_SHIFT) )
-set_iommu_ppr_log_control(iommu, IOMMU_CONTROL_DISABLED);
-
-if ( amd_iommu_has_feature(iommu, IOMMU_EXT_FEATURE_GTSUP_SHIFT) )
-set_iommu_guest_translation_control(iommu, IOMMU_CONTROL_DISABLED);
-
-set_iommu_translation_control(iommu, IOMMU_CONTROL_DISABLED);
-
-iommu->enabled = 0;
-
-spin_unlock_irqrestore(>lock, flags);
-
-}
-
 static void invalidate_all_domain_pages(void)
 {
 struct domain *d;





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

[Xen-devel] [xen-unstable-smoke test] 134519: trouble: blocked/broken/pass

[osstest service owner]

flight 134519 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134519/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 133991

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  1c6504163595d45e47a01750318c2b7b50541cbe
baseline version:
 xen  cb70a26f78848fe45f593f7ebc9cfaac760a791b

Last test of basis   133991  2019-03-22 15:00:46 Z   16 days
Failing since134068  2019-03-25 12:00:51 Z   13 days   62 attempts
Testing same since   134455  2019-04-05 18:00:45 Z2 days   13 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Brian Woods 
  Christian Lindig 
  Doug Goldstein 
  George Dunlap 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  M A Young 
  Norbert Manthey 
  Paul Durrant 
  Pawel Wieczorkiewicz 
  Petre Pircalabu 
  Razvan Cojocaru 
  Tamas K Lengyel 
  Wei Liu 
  Xiaochen Wang 
  Xin Li 

jobs:
 build-arm64-xsm  broken  
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary

broken-job build-arm64-xsm broken
broken-step build-arm64-xsm host-install(4)

Not pushing.

(No revision log; it would be 1487 lines long.)

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

[Xen-devel] [PATCH] x86/IOMMU: abstract Intel-specific adjust_vtd_irq_affinities()

[Jan Beulich]

This can't be folded into the resume hook, as that runs before bringin
back up APs, but the affinity adjustment wants to happen with all CPUs
back online. Hence a separate hook is needed such that AMD can then
leverage it as well.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -275,7 +275,7 @@ static int enter_state(u32 state)
 mtrr_aps_sync_begin();
 enable_nonboot_cpus();
 mtrr_aps_sync_end();
-adjust_vtd_irq_affinities();
+iommu_adjust_irq_affinities();
 acpi_dmar_zap();
 thaw_domains();
 system_state = SYS_STATE_active;
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2141,7 +2141,7 @@ static void adjust_irq_affinity(struct a
 dma_msi_set_affinity(irq_to_desc(drhd->iommu->msi.irq), cpumask);
 }
 
-int adjust_vtd_irq_affinities(void)
+static int adjust_vtd_irq_affinities(void)
 {
 struct acpi_drhd_unit *drhd;
 
@@ -2725,6 +2725,7 @@ const struct iommu_ops __initconstrel in
 .read_apic_from_ire = io_apic_read_remap_rte,
 .read_msi_from_ire = msi_msg_read_remap_rte,
 .setup_hpet_msi = intel_setup_hpet_msi,
+.adjust_irq_affinities = adjust_vtd_irq_affinities,
 .suspend = vtd_suspend,
 .resume = vtd_resume,
 .share_p2m = iommu_set_pgd,
--- a/xen/include/asm-x86/iommu.h
+++ b/xen/include/asm-x86/iommu.h
@@ -81,8 +81,14 @@ void iommu_update_ire_from_apic(unsigned
 unsigned int iommu_read_apic_from_ire(unsigned int apic, unsigned int reg);
 int iommu_setup_hpet_msi(struct msi_desc *);
 
+static inline int iommu_adjust_irq_affinities(void)
+{
+return iommu_ops.adjust_irq_affinities
+   ? iommu_ops.adjust_irq_affinities()
+   : 0;
+}
+
 /* While VT-d specific, this must get declared in a generic header. */
-int adjust_vtd_irq_affinities(void);
 int __must_check iommu_pte_flush(struct domain *d, u64 gfn, u64 *pte,
  int order, int present);
 
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -224,7 +224,10 @@ struct iommu_ops {
 
 void (*update_ire_from_apic)(unsigned int apic, unsigned int reg, unsigned 
int value);
 unsigned int (*read_apic_from_ire)(unsigned int apic, unsigned int reg);
+
 int (*setup_hpet_msi)(struct msi_desc *);
+
+int (*adjust_irq_affinities)(void);
 #endif /* CONFIG_X86 */
 
 int __must_check (*suspend)(void);





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

[Xen-devel] [PATCH v2] docs/xl: Clarify documentation for mem-max and mem-set

[George Dunlap]

mem-set is the primary command that users will need to use and
understand.  Move it first, and clarify the wording; also specify that
you can't set the target higher than maxmem from the domain config.

mem-max is actually a pretty useless command at the moment.  Clarify
that users are not expected to use it; and document all of its quirky
behavior.

Signed-off-by: George Dunlap 
---
v2:
- Reword memory unit section based on review feedback

I'm actully somewhat tempted to take out the entry for mem-max
entirely -- it's not at all clear to me what anyone would use it for,
and it's only likely to confuse people.

CC: Ian Jackson 
CC: Wei Liu 
CC: Andrew Cooper 
CC: Jan Beulich 
CC: Tim Deegan 
CC: Konrad Wilk 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Lars Kurth 
---
 docs/man/xl.1.pod.in | 75 +++-
 1 file changed, 53 insertions(+), 22 deletions(-)

diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in
index 4310fcd818..f44f054dfb 100644
--- a/docs/man/xl.1.pod.in
+++ b/docs/man/xl.1.pod.in
@@ -393,40 +393,71 @@ less utilized than a high CPU workload.  Consider 
yourself warned.
 
 =back
 
-=item B I I
+=item B I I
 
-Specify the maximum amount of memory the domain is able to use, appending 't'
-for terabytes, 'g' for gigabytes, 'm' for megabytes, 'k' for kilobytes and 'b'
-for bytes.
+Set the target for the domain's balloon driver.
 
-The mem-max value may not correspond to the actual memory used in the
-domain, as it may balloon down its memory to give more back to the OS.
+The default unit is kiB.  Add 't' for TiB, 'g' for GiB, 'm' for
+MiB, 'k' for kiB, and 'b' for bytes (e.g., `2048m` for 2048 MiB).
 
-The value given just sets the memory amount the domain is allowed to allocate
-in the hypervisor. It can't be set lower than the current reservation, but
-it is allowed to be higher than the configured maximum memory size of the
-domain (B parameter in the domain's configuration). Using B
-to set the maximum memory above the initial B value will not allow the
-additional memory to be used via B. The initial B value is
-still used as an upper limit for B.
+This must be less than the initial B parameter in the domain's
+configuration.
 
-The domain will not receive any signal regarding the changed memory limit.
+Note that this operation requests the guest operating system's balloon
+driver to reach the target amount of memory.  The guest may fail to
+reach that amount of memory for any number of reasons, including:
 
-=item B I I
+=over 4
+
+=item
+
+The guest doesn't have a balloon driver installed
+
+=item
+
+The guest's balloon driver is buggy
+
+=item
+
+The guest's balloon driver cannot create free guest memory due to
+guest memory pressure
+
+=item
 
-Set the domain's used memory using the balloon driver; append 't' for
-terabytes, 'g' for gigabytes, 'm' for megabytes, 'k' for kilobytes and 'b' for
-bytes.
+The guest's balloon driver cannot allocate memory from Xen because of
+hypervisor memory pressure
 
-Because this operation requires cooperation from the domain operating
-system, there is no guarantee that it will succeed.  This command will
-definitely not work unless the domain has the required paravirt
-driver.
+=item
+
+The guest administrator has disabled the balloon driver
+
+=back
 
 B There is no good way to know in advance how small of a
 mem-set will make a domain unstable and cause it to crash.  Be very
 careful when using this command on running domains.
 
+=item B I I
+
+Specify the limit Xen will place on the amount of memory a guest may
+allocate.
+
+The default unit is kiB.  Add 't' for TiB, 'g' for GiB, 'm' for
+MiB, 'k' for kiB, and 'b' for bytes (e.g., `2048m` for 2048 MiB).
+
+NB that users normally shouldn't need this command; B will
+set this as appropriate automatically.
+
+I can't be set lower than the current memory target for
+I.  It is allowed to be higher than the configured maximum
+memory size of the domain (B parameter in the domain's
+configuration). Note however that the initial B value is still
+used as an upper limit for B.  Also note that calling B will reset this value.
+
+The domain will not receive any signal regarding the changed memory
+limit.
+
 =item B [I] I I
 
 Migrate a domain to another host machine. By default B relies on ssh as a
-- 
2.20.1


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

Re: [Xen-devel] [PATCH] x86/livepatch: Fail the build if duplicate symbols exist

[Jan Beulich]

>>> On 08.04.19 at 12:11,  wrote:
> On 08/04/2019 10:52, Jan Beulich wrote:
> On 05.04.19 at 23:02,  wrote:
>>> On Fri, Apr 05, 2019 at 08:26:04PM +0100, Andrew Cooper wrote:
 From: Ross Lagerwall 

 The binary diffing algorithm used by xen-livepatch depends on having unique
 symbols.
>> Question: Is this an inherent requirement, or an effect of the
>> current implementation? It would seem to me that at least in the
>> common case (binary didn't changer overly heavily) it ought to
>> be possible to re-associate the duplicates with their correct
>> origins. And by making the build fail (including in cases like the
>> one we have right now), we're painting ourselves into the
>> corner of having to "fix" code which isn't actually buggy.
> 
> It is inherent.  The tool needs a unique way to identify each block of
> code, so it can work out if the binary has changed by more than just
> relocations.
> 
> How do you propose disambiguating ambiguous symbols after the fact?
> 
> (This is semi rhetorical, because even if there is a possible way, there
> is no plausible way it is the sensible option to take.)

I don't understand why you consider it impossible for this to be a
sensible option.

First of all, from the very beginning of live-patching's existence I've
been questioning it having got made dependent on the internal
symbol table we generate, for there being a chance of it being
broken in some way.

As to disambiguating: Other nearby local symbols could surely
help. This might be a problem with -ffunction-sections, but other
than I thought we don't appear to be using it - at least I couldn't
get grep to produce a hit in xen/, config/, and the tree root.

Finally we likely could avoid the ambiguities altogether, e.g. by
making the compiler emit (relative) directories when populating
STT_FILE symbols. We already qualify multiply compiled source
files by an object file name; I don't see why we couldn't also
suitably qualify singly compiled files (and perhaps there's even
a compiler option, such that we wouldn't need to issue .file
assembler directives ourselves).

Another possibility to avoid (false) ambiguities could be to make
the non-inline expansions of intended-to-be-inline functions
link-once (which by implication means non-static, and hence
necessarily uniquely named).

>> Was the option of altering (amending) the symbol name instead
>> of causing failure considered?
> 
> Amending how?  We've already got one bodge to prepend the filename to
> static symbols.

Right, in an attempt to disambiguate them. If the file names
included (relative) paths, this would have been enough. Since
they don't (for now at least), a sequence number might help.

>> Again, in the common case this
>> shouldn't have overly bad implications: Typically the order of
>> symbols wouldn't change between builds, so tagging the
>> duplicates with a sequence number might be good enough.
> 
> This is painting ourselves into a corner with LTO.

Hmm, yes, it all would depend on the amount of churn
between builds.

> Also, this reasoning depends on people only making trivial changes via
> livepatch, which, as it turns out, isn't the case in practice.
> 
>> And even if the order changed, as long as both instances in fact
>> derive from the same inline function, all would still be fine afaict.
> 
> How do you propose that we determine this?

We build with debug info, so it ought to be possible in principle
to know that both have the same source origin.

>> Granted there's some heuristic underlying this, in that we then
>> would hope for there not to be actually differing functions with
>> the same source file and symbol names.
> 
> The more assumptions we start making, the more subtly this will go wrong
> in the future.

Yes, I agree - that's the main downside. But failing a build is
a pretty meaningful downside as well, the more when people
may not build with LIVEPATCH=y before they submit. (FTR,
personally I wouldn't consider it appropriate to revert in such
a case, as an issue here has nothing to do with the actual
change, but only with how we post-process data.) And even
if they did, compiler (version) differences may make them not
notice any issue. For this last reason even automatic testing
(osstest or else) may end up assuming all is fine when it's not.

Jan


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

Re: [Xen-devel] [PATCH v2] xen/timers: Fix memory leak with cpu unplug/plug

[Andrew Cooper]

On 08/04/2019 11:39, Julien Grall wrote:
> Hi,
>
> On 4/8/19 10:39 AM, Andrew Cooper wrote:
>> +    case CPU_RESUME_FAILED:
>> +    if ( !park_offline_cpus && system_state != SYS_STATE_suspend )
>
> This patch breaks compilation on arm32/arm64 because park_offline_cpus
> is not defined:
>
> timer.c: In function 'cpu_callback':
> timer.c:651:15: error: 'park_offline_cpus' undeclared (first use in
> this function)
>  if ( !park_offline_cpus && system_state != SYS_STATE_suspend )
>    ^
>
> What is the purpose of park_offline_cpus?

Sorry.  I should have waited for a full build test first.

park_offline_cpus is a workaround for Intel's MCE behaviour, where the
system will shut down rather than deliver an #MC if machine checking
isn't configured on all CPUs.

As a result, we have to start all CPUs, even beyond maxcpus= and set up
machine check handling, and never ever free their stacks, even if we'd
prefer the CPUs to be offline.

Are you happy with a

#define park_offline_cpus false

in ARM?

~Andrew

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

Re: [Xen-devel] [PATCH v4 09/10] tools/arm: tee: add "tee" option for xl.cfg

[Julien Grall]

Hi,

On 4/5/19 11:25 AM, Volodymyr Babchuk wrote:


Hi Julien,

Julien Grall writes:


Hi,

On 20/03/2019 17:01, Volodymyr Babchuk wrote:


Julien Grall writes:


On 20/03/2019 15:27, Volodymyr Babchuk wrote:


Hello Julien,

Julien Grall writes:


On 07/03/2019 21:04, Volodymyr Babchuk wrote:

From: Volodymyr Babchuk 

This enumeration controls TEE type for a domain. Currently there is
two possible options: either 'none' or 'native'.

'none' is the default value and it basically disables TEE support at
all.

'native' enables access to a "real" TEE installed on a platform.


I am aware I made that suggestion. But I think the naming is not ideal
between the user and the toolstack. The question is how this is going
to fit with the S-EL2 feature where multiple TEE can run together?

You see, support for S-EL2 or support for multiple TEEs is a much broader
topic. For me, naming for configuration option is the least important
thing in this case :-)


Naming exposed to users are hard to remove. If the naming is too
ambiguous, then we will have to introduce a new option later on. This
is not very ideal, so it would be better if we can find something
different.



Right there is no clear vision how it will ever work. I scanned through
SPCI spec and I already have a couple of questions. I need to study it
harder to make serious statements, but I already see that current
mediator framework will hardly fit into SPCI stuff. Frankly, I have
concerns that OP-TEE (or any other existing TEE) will be compatible
with SPCI-enabled systems without major rework. So, we will need to do
big overhaul anyways, when there will appear first SPCI-compatible TEEs and
secure hypervisors.

AFAIK, there is no ARMv8.4 platforms, no S-EL2 hypervisors and so on. It
will take at least couple of years before S-EL2 will hit the market. So
in my opinion it is too early to make any assumptions on how to support
all this in Xen. Lets stick to the current matters.


I am fully aware that more work will need to be done with S-EL2. I am
not expecting you (or anyone else here) to come with the
implementation now. My point is the naming should be chosen so it
prevents ambiguity with whatever we know will come up in the future.



I'm not insisting on "native". But I can't invent something better right
now. Probably, SPCI-enabled TEE also will be considered "native" as
opposed to, say, "emulated". >
As I said, I can't come with anything better than "native". But I'm open
to any suggestions.


Well one solution is to ditch "native" and name it "optee". By giving
the name you avoid ambiguity. If we ever have multiple op-tee instance
running, then it could easily be extend with a comma. So you allow
backward compatibility.


I considered this. But If I remember right, idea was to query Xen about
available TEE, and configure guest in the appropriate way. So "native"
(or some other generic way) could be used for OP-TEE, Google Trusty or
any other TEE, without changing guest configuration.

Using "optee" will cause explicit configuration for OP-TEE only. I can't
say that this is good or bad. It just different. Do you think that would
be better approach?


You have 2 different cases to take into account:
- A guest is able to deal with all supported Trusted OS. So
"native" will let the toolstack query the current Trusted OS and
expose it to the guest.
- A guest can only deal with a specific Trusted OS. In that case,
the user might want to specify in the configuration the expected
Trusted OS so it can't boot if not available.

What I suggest is deferring the former case until we have another TEE
in hand. Maybe at that time, we will have a better naming :).


Okay, so summarizing this up, you are proposing to use "optee". Am I got
you right?


I am suggesting 'tee = "optee"' for now.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC 00/39] x86/KVM: Xen HVM guest support

[Juergen Gross]

On 08/04/2019 12:36, Joao Martins wrote:
> On 4/8/19 7:44 AM, Juergen Gross wrote:
>> On 12/03/2019 18:14, Joao Martins wrote:
>>> On 2/22/19 4:59 PM, Paolo Bonzini wrote:
 On 21/02/19 12:45, Joao Martins wrote:
> On 2/20/19 9:09 PM, Paolo Bonzini wrote:
>> On 20/02/19 21:15, Joao Martins wrote:
>>>  2. PV Driver support (patches 17 - 39)
>>>
>>>  We start by redirecting hypercalls from the backend to routines
>>>  which emulate the behaviour that PV backends expect i.e. grant
>>>  table and interdomain events. Next, we add support for late
>>>  initialization of xenbus, followed by implementing
>>>  frontend/backend communication mechanisms (i.e. grant tables and
>>>  interdomain event channels). Finally, introduce xen-shim.ko,
>>>  which will setup a limited Xen environment. This uses the added
>>>  functionality of Xen specific shared memory (grant tables) and
>>>  notifications (event channels).
>>
>> I am a bit worried by the last patches, they seem really brittle and
>> prone to breakage.  I don't know Xen well enough to understand if the
>> lack of support for GNTMAP_host_map is fixable, but if not, you have to
>> define a completely different hypercall.
>>
> I guess Ankur already answered this; so just to stack this on top of his 
> comment.
>
> The xen_shim_domain() is only meant to handle the case where the backend
> has/can-have full access to guest memory [i.e. netback and blkback would 
> work
> with similar assumptions as vhost?]. For the normal case, where a backend 
> *in a
> guest* maps and unmaps other guest memory, this is not applicable and 
> these
> changes don't affect that case.
>
> IOW, the PV backend here sits on the hypervisor, and the hypercalls aren't
> actual hypercalls but rather invoking shim_hypercall(). The call chain 
> would go
> more or less like:
>
> 
>  gnttab_map_refs(map_ops, pages)
>HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,...)
>  shim_hypercall()
>shim_hcall_gntmap()
>
> Our reasoning was that given we are already in KVM, why mapping a page if 
> the
> user (i.e. the kernel PV backend) is himself? The lack of GNTMAP_host_map 
> is how
> the shim determines its user doesn't want to map the page. Also, there's 
> another
> issue where PV backends always need a struct page to reference the device
> inflight data as Ankur pointed out.

 Ultimately it's up to the Xen people.  It does make their API uglier,
 especially the in/out change for the parameter.  If you can at least
 avoid that, it would alleviate my concerns quite a bit.
>>>
>>> In my view, we have two options overall:
>>>
>>> 1) Make it explicit, the changes the PV drivers we have to make in
>>> order to support xen_shim_domain(). This could mean e.g. a) add a callback
>>> argument to gnttab_map_refs() that is invoked for every page that gets 
>>> looked up
>>> successfully, and inside this callback the PV driver may update it's 
>>> tracking
>>> page. Here we no longer have this in/out parameter in gnttab_map_refs, and 
>>> all
>>> shim_domain specific bits would be a little more abstracted from Xen PV
>>> backends. See netback example below the scissors mark. Or b) have sort of a
>>> translate_gref() and put_gref() API that Xen PV drivers use which make it 
>>> even
>>> more explicit that there's no grant ops involved. The latter is more 
>>> invasive.
>>>
>>> 2) The second option is to support guest grant mapping/unmapping [*] to 
>>> allow
>>> hosting PV backends inside the guest. This would remove the Xen changes in 
>>> this
>>> series completely. But it would require another guest being used
>>> as netback/blkback/xenstored, and less performance than 1) (though, in 
>>> theory,
>>> it would be equivalent to what does Xen with grants/events). The only 
>>> changes in
>>> Linux Xen code is adding xenstored domain support, but that is useful on 
>>> its own
>>> outside the scope of this work.
>>>
>>> I think there's value on both; 1) is probably more familiar for KVM users
>>> perhaps (as it is similar to what vhost does?) while  2) equates to 
>>> implementing
>>> Xen disagregation capabilities in KVM.
>>>
>>> Thoughts? Xen maintainers what's your take on this?
>>
>> What I'd like best would be a new handle (e.g. xenhost_t *) used as an
>> abstraction layer for this kind of stuff. It should be passed to the
>> backends and those would pass it on to low-level Xen drivers (xenbus,
>> event channels, grant table, ...).
>>
> So if IIRC backends would use the xenhost layer to access grants or frames
> referenced by grants, and that would grok into some of this. IOW, you would 
> have
> two implementors of xenhost: one for nested remote/local events+grants and
> another for this "shim domain" ?

As I'd need that for nested Xen I guess that would make it 3 variants.

Re: [Xen-devel] [PATCH v2] xen/timers: Fix memory leak with cpu unplug/plug

[Julien Grall]

Hi,

On 4/8/19 10:39 AM, Andrew Cooper wrote:

+case CPU_RESUME_FAILED:
+if ( !park_offline_cpus && system_state != SYS_STATE_suspend )


This patch breaks compilation on arm32/arm64 because park_offline_cpus 
is not defined:


timer.c: In function 'cpu_callback':
timer.c:651:15: error: 'park_offline_cpus' undeclared (first use in this 
function)

 if ( !park_offline_cpus && system_state != SYS_STATE_suspend )
   ^

What is the purpose of park_offline_cpus?

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC 00/39] x86/KVM: Xen HVM guest support

[Joao Martins]

On 4/8/19 7:44 AM, Juergen Gross wrote:
> On 12/03/2019 18:14, Joao Martins wrote:
>> On 2/22/19 4:59 PM, Paolo Bonzini wrote:
>>> On 21/02/19 12:45, Joao Martins wrote:
 On 2/20/19 9:09 PM, Paolo Bonzini wrote:
> On 20/02/19 21:15, Joao Martins wrote:
>>  2. PV Driver support (patches 17 - 39)
>>
>>  We start by redirecting hypercalls from the backend to routines
>>  which emulate the behaviour that PV backends expect i.e. grant
>>  table and interdomain events. Next, we add support for late
>>  initialization of xenbus, followed by implementing
>>  frontend/backend communication mechanisms (i.e. grant tables and
>>  interdomain event channels). Finally, introduce xen-shim.ko,
>>  which will setup a limited Xen environment. This uses the added
>>  functionality of Xen specific shared memory (grant tables) and
>>  notifications (event channels).
>
> I am a bit worried by the last patches, they seem really brittle and
> prone to breakage.  I don't know Xen well enough to understand if the
> lack of support for GNTMAP_host_map is fixable, but if not, you have to
> define a completely different hypercall.
>
 I guess Ankur already answered this; so just to stack this on top of his 
 comment.

 The xen_shim_domain() is only meant to handle the case where the backend
 has/can-have full access to guest memory [i.e. netback and blkback would 
 work
 with similar assumptions as vhost?]. For the normal case, where a backend 
 *in a
 guest* maps and unmaps other guest memory, this is not applicable and these
 changes don't affect that case.

 IOW, the PV backend here sits on the hypervisor, and the hypercalls aren't
 actual hypercalls but rather invoking shim_hypercall(). The call chain 
 would go
 more or less like:

 
  gnttab_map_refs(map_ops, pages)
HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,...)
  shim_hypercall()
shim_hcall_gntmap()

 Our reasoning was that given we are already in KVM, why mapping a page if 
 the
 user (i.e. the kernel PV backend) is himself? The lack of GNTMAP_host_map 
 is how
 the shim determines its user doesn't want to map the page. Also, there's 
 another
 issue where PV backends always need a struct page to reference the device
 inflight data as Ankur pointed out.
>>>
>>> Ultimately it's up to the Xen people.  It does make their API uglier,
>>> especially the in/out change for the parameter.  If you can at least
>>> avoid that, it would alleviate my concerns quite a bit.
>>
>> In my view, we have two options overall:
>>
>> 1) Make it explicit, the changes the PV drivers we have to make in
>> order to support xen_shim_domain(). This could mean e.g. a) add a callback
>> argument to gnttab_map_refs() that is invoked for every page that gets 
>> looked up
>> successfully, and inside this callback the PV driver may update it's tracking
>> page. Here we no longer have this in/out parameter in gnttab_map_refs, and 
>> all
>> shim_domain specific bits would be a little more abstracted from Xen PV
>> backends. See netback example below the scissors mark. Or b) have sort of a
>> translate_gref() and put_gref() API that Xen PV drivers use which make it 
>> even
>> more explicit that there's no grant ops involved. The latter is more 
>> invasive.
>>
>> 2) The second option is to support guest grant mapping/unmapping [*] to allow
>> hosting PV backends inside the guest. This would remove the Xen changes in 
>> this
>> series completely. But it would require another guest being used
>> as netback/blkback/xenstored, and less performance than 1) (though, in 
>> theory,
>> it would be equivalent to what does Xen with grants/events). The only 
>> changes in
>> Linux Xen code is adding xenstored domain support, but that is useful on its 
>> own
>> outside the scope of this work.
>>
>> I think there's value on both; 1) is probably more familiar for KVM users
>> perhaps (as it is similar to what vhost does?) while  2) equates to 
>> implementing
>> Xen disagregation capabilities in KVM.
>>
>> Thoughts? Xen maintainers what's your take on this?
> 
> What I'd like best would be a new handle (e.g. xenhost_t *) used as an
> abstraction layer for this kind of stuff. It should be passed to the
> backends and those would pass it on to low-level Xen drivers (xenbus,
> event channels, grant table, ...).
> 
So if IIRC backends would use the xenhost layer to access grants or frames
referenced by grants, and that would grok into some of this. IOW, you would have
two implementors of xenhost: one for nested remote/local events+grants and
another for this "shim domain" ?

> I was planning to do that (the xenhost_t * stuff) soon in order to add
> support for nested Xen using PV devices (you need two Xenstores for that
> as the nested dom0 is acting as Xen backend server, while using PV
> frontends for