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
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-pvops
> 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
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
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
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
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
> 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
> 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
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
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
> 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
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
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,
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
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
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-pvops
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
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
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
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,
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
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
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
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
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)
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),
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
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
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
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
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
>>> 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
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
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
>>> 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
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
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
---
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
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
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
>>> 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
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
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
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
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
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 |
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
---
"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
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
---
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:
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/Xen.c | 7 +++
2 files changed, 12 insertions(+)
diff --git a/OvmfPkg/XenPlatformPei/Platform.h
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
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(+)
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
.. 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
---
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
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
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
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
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
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
---
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(-)
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():
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
---
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
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
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
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
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:
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
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
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
>>> 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
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 &&
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
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
> >
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
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
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
>>> 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,
>>> {
>>> /*
>>>
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 !=
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.
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
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
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
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
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
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
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
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
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
+++
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
>>> 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
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:
>
>
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:
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
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:
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
1 - 100 of 132 matches
Mail list logo
