On 14/04/2019 17:07, Julien Grall wrote:
> Hi,
>
> On 4/14/19 3:33 PM, Amit Singh Tomar wrote:
>> At the moment, we hide PMU's from domain 0 and XEN boot fails on
>> platform[1]
>> where DTS contains "arm,cortex-a53-pmu" as compatible string for PMU
>> node.
>
> "Domain 0 and Xen boot fails" is p
>>> Andrew Cooper 04/12/19 9:17 PM >>>
>Ever since its introducion in c/s 436fb462 "x86/microcode: enable boot
>time (pre-Dom0) loading", the allocation has gone un-freed, and has its final
>use as part of constructing dom0.
>
>Xen already consideres it an error to have more than a single unaccoun
>>> Andrew Cooper 04/13/19 6:22 PM >>>
>It has ended up in the middle of the mitigation calculation logic. Move it to
>be beside the other command line parsing.
>
>No functional change.
>
>Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
___
Xen
On 15/04/2019 08:55, Jan Beulich wrote:
Andrew Cooper 04/12/19 9:17 PM >>>
>> Ever since its introducion in c/s 436fb462 "x86/microcode: enable boot
>> time (pre-Dom0) loading", the allocation has gone un-freed, and has its final
>> use as part of constructing dom0.
>>
>> Xen already consider
>>> Andrew Cooper 04/13/19 6:22 PM >>>---
>>> a/xen/arch/x86/msr.c+++ b/xen/arch/x86/msr.c
>@@ -131,6 +131,7 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr,
>uint64_t *val)
>case MSR_PRED_CMD:
>case MSR_FLUSH_CMD:
>/* Write-only */
>+case MSR_INTEL_CORE_THREAD_COUNT:
>case MSR_TSX_FOR
Hello,
> After talking via IRC, the problem is PPIs, that this platform uses for
> PMU interrupts. When Xen tries to setup the IRQ forwarding for Dom0 for
> this device, it fails because it only supports forwarding SPIs.
> So interestingly we erroneously forwarded A53 PMUs (those that are
> descri
flight 134805 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134805/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 133991
Tests which
>>> Andrew Cooper 04/13/19 6:22 PM >>>
>--- a/xen/arch/x86/spec_ctrl.c
>+++ b/xen/arch/x86/spec_ctrl.c
>@@ -58,7 +58,7 @@ uint8_t __read_mostly default_xen_spec_ctrl;
>uint8_t __read_mostly default_spec_ctrl_flags;
>
>paddr_t __read_mostly l1tf_addr_mask, __read_mostly l1tf_safe_maddr;
>-static b
On 15/04/2019 09:09, Jan Beulich wrote:
Andrew Cooper 04/13/19 6:22 PM >>>---
a/xen/arch/x86/msr.c+++ b/xen/arch/x86/msr.c
>> @@ -131,6 +131,7 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr,
>> uint64_t *val)
>> case MSR_PRED_CMD:
>> case MSR_FLUSH_CMD:
>> /* Write-only */
>> +
On Mon, 15 Apr 2019 13:41:41 +0530
Amit Tomer wrote:
> Hello,
>
> > After talking via IRC, the problem is PPIs, that this platform uses for
> > PMU interrupts. When Xen tries to setup the IRQ forwarding for Dom0 for
> > this device, it fails because it only supports forwarding SPIs.
> > So inter
On Wed, Apr 10, 2019 at 03:20:05PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> > Sent: 10 April 2019 13:57
> > To: Paul Durrant
> > Cc: qemu-de...@nongnu.org; qemu-bl...@nongnu.org;
> > xen-devel@lists.xenproject.org; Ste
Hi Juergen,
Although xen-stable-4.12 is released now for some time (thanks for the timely
release !),
the release tag "RELEASE-4.12.0" is still only available in the "staging-4.12"
branch of the Xen git tree.
The "stable-4.12" is still a few (release-) commits short, it seems a bit
awkward.
On Tue, Apr 09, 2019 at 06:53:47PM +0100, Andrew Cooper wrote:
> @@ -692,6 +692,7 @@ unsigned long hvm_get_shadow_gs_base(struct vcpu *v);
> void hvm_set_info_guest(struct vcpu *v);
> void hvm_cpuid_policy_changed(struct vcpu *v);
> void hvm_set_tsc_offset(struct vcpu *v, uint64_t offset, uint64
The code for getting the entry and then populating was repeated in
p2m_change_altp2m_gfn() and in p2m_set_altp2m_mem_access().
The code is now in one place with a bool param that lets the caller choose
if it populates after get_entry().
If remapping is being done then both the old and new gfn's s
On Sat, Apr 13, 2019 at 11:17:48AM +0800, Kevin Buckley wrote:
> On Thu, 11 Apr 2019 at 18:29, Wei Liu wrote:
> >
> > ...
> > Sure. I will write a patch.
> >
> > Wei.
>
> Couple of other things I noticed after posting the original observation,
> that might be of use in patching the documentation
On 15/04/2019 11:03, Wei Liu wrote:
> On Tue, Apr 09, 2019 at 06:53:47PM +0100, Andrew Cooper wrote:
>> @@ -692,6 +692,7 @@ unsigned long hvm_get_shadow_gs_base(struct vcpu *v);
>> void hvm_set_info_guest(struct vcpu *v);
>> void hvm_cpuid_policy_changed(struct vcpu *v);
>> void hvm_set_tsc_offs
On Mon, Apr 15, 2019 at 10:23:58AM +0100, Wei Liu wrote:
> > 2)
> >
> > In the top-level INSTALL file, we read
> >
> > 8<8<8<8<8<8<8<8<
> > SMBIOS_REL_DATE=mm/dd/
> > VGABIOS_REL_DATE="dd Mon "
> >
> > During tools build ext
flight 83972 distros-debian-sid real [real]
http://osstest.xensource.com/osstest/logs/83972/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
flight 134697 qemu-upstream-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134697/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken in 134594
build-arm64-pvop
On Wed, Apr 10, 2019 at 11:32:10AM +0200, Laszlo Ersek wrote:
> On 04/09/19 13:08, Anthony PERARD wrote:
> > 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,
On Thu, Apr 11, 2019 at 01:52:27PM +0100, Andrew Cooper wrote:
> On 09/04/2019 12:08, Anthony PERARD wrote:
> > diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> > b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
> > new file mode 100644
> > index 00..c4802bf4d1
> > --- /dev/null
> > +
On 14.04.19 19:55, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 4/8/19 11:14 AM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Extend driver to be able to handle other SCIF(X) compatible
interfaces as well. These interfaces have lot in common,
but mostly differ in offsets and
On 14.04.19 20:48, Julien Grall wrote:
Hi,
Hi Julien
On 4/8/19 11:14 AM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Extend early prink code to be able to handle other SCIF(X)
compatible interfaces as well. These interfaces have lot in common,
but mostly differ in offsets and
On 14.04.19 20:56, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 4/8/19 11:14 AM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch makes possible to use existing early prink code
for Renesas "Stout" board based on R-Car H2 SoC (SCIFA).
The "EARLY_PRINTK_VERSION" for t
For some broken hosts we explicitly force the mac address in
software. (This is controlled by the ForceMacAddress host property.)
We achieve this by writing a udev rule (which ends up both in the
installer and in the initramfs) which calls `ip link set ... address'.
However: in some cases we sha
* Fix the shim build by providing a !CONFIG_HVM declaration for
hvm_get_guest_bndcfgs(), and removing the introduced
ASSERT(is_hvm_domain(d))'s. They are needed for DCE to keep the build
working. Furthermore, in this way, the risk of runtime type confusion is
removed.
* Revert the d
flight 134809 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134809/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 133991
Tests which
flight 134802 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134802/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 6 kernel-build fail REGR. vs. 134640
build-i386-libvirt
On 15/04/2019 09:25, Jan Beulich wrote:
Andrew Cooper 04/13/19 6:22 PM >>>
>> --- a/xen/arch/x86/spec_ctrl.c
>> +++ b/xen/arch/x86/spec_ctrl.c
>> @@ -58,7 +58,7 @@ uint8_t __read_mostly default_xen_spec_ctrl;
>> uint8_t __read_mostly default_spec_ctrl_flags;
> >
>> paddr_t __read_mostly l1tf
On 04/09/19 13:08, Anthony PERARD wrote:
> Linux panic if this region isn't reserved.
Please expand "this" (just copy from the subject).
with that,
Acked-by: Laszlo Ersek
Thanks
Laszlo
>
> When Linux is booted on EFI system, it expects the memory at 0xa to
> _not_ be conventional memory.
On 15/04/2019 12:25, Anthony PERARD wrote:
> On Thu, Apr 11, 2019 at 01:52:27PM +0100, Andrew Cooper wrote:
>> On 09/04/2019 12:08, Anthony PERARD wrote:
>>> diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
>>> b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
>>> new file mode 100644
>>> index
On 04/09/19 13:08, Anthony PERARD wrote:
> 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:
>
On 04/15/19 15:29, Laszlo Ersek wrote:
> On 04/09/19 13:08, Anthony PERARD wrote:
>> 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: Antho
On 04/09/19 13:08, Anthony PERARD wrote:
> 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/Platfo
Greetings,
I've found a way to crash a host from a misbehaving guest, using altp2m.
This is on a recent Intel core i7 chip. I've crashed two systems running
4.11.1. This behavior is not exhibited on 4.12, and since altp2m is a tech
preview in 4.11.1, this is not covered by security support. Howeve
On 09/04/2019 12:08, Anthony PERARD wrote:
> 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 0
On Fri, Apr 12, 2019 at 01:15:48PM +0200, Laszlo Ersek wrote:
> On 04/09/19 13:08, Anthony PERARD wrote:
> > 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
Hello Matt,
Judging by the description of your problem, I believe that it has
already been fixed by this commit:
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=1dddfff4c39d3db17dfa709b1c57f44e3ed352e3;hp=68465944c81fa2fbc40bf29ec6084072af5e48ec
Could you please either try to reproduc
On 4/15/19 10:22 AM, Alexandru Stefan ISAILA wrote:
> The code for getting the entry and then populating was repeated in
> p2m_change_altp2m_gfn() and in p2m_set_altp2m_mem_access().
>
> The code is now in one place with a bool param that lets the caller choose
> if it populates after get_entry().
On 04/15/19 15:33, Laszlo Ersek wrote:
> On 04/09/19 13:08, Anthony PERARD wrote:
>> 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: An
On 04/09/19 13:08, Anthony PERARD wrote:
> That value is used by SecPeiDxeTimerLibCpu, the TimerLib implementation.
> It will also be used by XenTimerDxe.
(1) please expand "that value".
with that,
Acked-by: Laszlo Ersek
Thanks
Laszlo
>
> Contributed-under: TianoCore Contribution Agreement 1
Hi Razvan,
You are correct -- cherry picking that commit into RELEASE-4.11.1 addresses
the crash. The problem cannot be reproduced on 4.12.
I hope this helps.
Kind regards,
Matt
On Mon, Apr 15, 2019 at 8:43 AM Razvan Cojocaru
wrote:
> Hello Matt,
>
> Judging by the description of your proble
On 04/09/19 13:08, Anthony PERARD wrote:
> "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
On 4/15/19 5:04 PM, Matt Leinhos wrote:
You are correct -- cherry picking that commit into RELEASE-4.11.1
addresses the crash. The problem cannot be reproduced on 4.12.
I hope this helps.
Thank you for confirming the fix!
To the deciders: would it be reasonable to ask patches like this to be
On Mon, Apr 15, 2019 at 03:49:25PM +0200, Laszlo Ersek wrote:
> On 04/15/19 15:33, Laszlo Ersek wrote:
> > On 04/09/19 13:08, Anthony PERARD wrote:
> >> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> >> b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> >> index 12303fb0
On 04/09/19 13:08, Anthony PERARD wrote:
> 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
(1) ITYM "that *
flight 134704 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134704/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken in 134598
build-arm64-xsm
>>> Andrew Cooper 04/15/19 10:30 AM >>>
>On 15/04/2019 09:09, Jan Beulich wrote:
Andrew Cooper 04/13/19 6:22 PM
>>>--- a/xen/arch/x86/msr.c+++ b/xen/arch/x86/msr.c
>>> @@ -131,6 +131,7 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr,
>>> uint64_t *val)
>>> case MSR_PRED_CMD:
>>> cas
On 4/12/19 8:47 PM, Tamas K Lengyel wrote:
> Patch 0502e0adae2 "x86: correct instances of PGC_allocated clearing"
> introduced
> grabbing extra references for pages that drop references tied to
> PGC_allocated.
> However, the way these extra references were grabbed were incorrect, resulting
> in
On Mon, Apr 15, 2019 at 9:21 AM George Dunlap wrote:
>
> On 4/12/19 8:47 PM, Tamas K Lengyel wrote:
> > Patch 0502e0adae2 "x86: correct instances of PGC_allocated clearing"
> > introduced
> > grabbing extra references for pages that drop references tied to
> > PGC_allocated.
> > However, the way
>>> Alexandru Stefan ISAILA 04/15/19 11:23 AM >>>
>--- a/xen/include/asm-x86/p2m.h
>+++ b/xen/include/asm-x86/p2m.h
>@@ -514,6 +514,23 @@ static inline unsigned long mfn_to_gfn(struct domain *d,
>mfn_t mfn)
>return mfn_x(mfn);
>}
>
>+int get_altp2m_entry(struct p2m_domain *ap2m, gfn_t g
>>> Andrew Cooper 04/15/19 2:03 PM >>>
>* Fix the shim build by providing a !CONFIG_HVM declaration for
>hvm_get_guest_bndcfgs(), and removing the introduced
>ASSERT(is_hvm_domain(d))'s. They are needed for DCE to keep the build
>working. Furthermore, in this way, the risk of runtime type confu
flight 134822 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134822/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 133991
Tests which
In d290e325179ccee966cd679d0fed48be6f4cc1b7
"build system: don't let install-stubdom depend on install-tools"
the dependency of install-stubdom on install-tools was removed.
However, this was not correct. stubdom/Makefile contains this:
$(XEN_ROOT)/tools/qemu-xen-traditional-dir:
$(M
Ian Jackson (2):
build system: make install-stubdom depend on install-tools again
DO NOT APPLY git-checkout.sh: add sleep to demonstrate race
Makefile| 2 +-
scripts/git-checkout.sh | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
--
2.11.0
_
This allows easy reproduction of git-checkout races: each checkout
waits until you kill its sleep. You can see the multiple identical
checkout runes in ps etc. A good rune is:
watch 'ps -fHtpts/60'
(replacing pts/60 with the pty of your build job).
Signed-off-by: Ian Jackson
---
scripts/git-
flight 134811 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134811/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 66dd3f2bd67f9380116d2d0210fef816b154bf7a
baseline version:
freebsd 831bf1a1aa1
> On Apr 15, 2019, at 4:31 PM, Tamas K Lengyel wrote:
>
> On Mon, Apr 15, 2019 at 9:21 AM George Dunlap
> wrote:
>>
>> On 4/12/19 8:47 PM, Tamas K Lengyel wrote:
>>> Patch 0502e0adae2 "x86: correct instances of PGC_allocated clearing"
>>> introduced
>>> grabbing extra references for pages t
On Mon, Apr 15, 2019 at 11:28 AM George Dunlap wrote:
>
>
>
> > On Apr 15, 2019, at 4:31 PM, Tamas K Lengyel wrote:
> >
> > On Mon, Apr 15, 2019 at 9:21 AM George Dunlap
> > wrote:
> >>
> >> On 4/12/19 8:47 PM, Tamas K Lengyel wrote:
> >>> Patch 0502e0adae2 "x86: correct instances of PGC_alloca
On 04/15/19 16:40, Anthony PERARD wrote:
> On Mon, Apr 15, 2019 at 03:49:25PM +0200, Laszlo Ersek wrote:
>> On 04/15/19 15:33, Laszlo Ersek wrote:
>>> On 04/09/19 13:08, Anthony PERARD wrote:
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
b/OvmfPkg/Library/PlatformBoot
flight 134708 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134708/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 119195
Tests which did n
flight 134827 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134827/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 133991
Tests which
Hi,
On 4/15/19 7:28 PM, osstest service owner wrote:
> flight 134708 linux-arm-xen real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/134708/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-arm64-arm64-examine
In preparation to enabling -Wimplicit-fallthrough, mark switch
cases where we are expecting to fall through.
This patch fixes the following warning:
drivers/net/xen-netfront.c: In function ‘netback_changed’:
drivers/net/xen-netfront.c:2038:6: warning: this statement may fall through
[-Wimplicit-
On Mon, 18 Feb 2019, Julien Grall wrote:
> mfn_to_pdx adds more safety than pfn_to_pdx. Replace all but on place in
> the Arm code to use the former.
This is good but maybe we can go even further.
You should also be able to replace one call site of pfn_to_pdx in
mfn_valid and the one in maddr_to_
On Mon, 18 Feb 2019, Julien Grall wrote:
> No functional changes intended.
Please list here the changes this patch is making:
- renaming gnttab_shared_gmfn to gnttab_shared_gfn to follow the naming
convention (and others.)
- making gnttab_shared_gmfn returning gfn_t
With the better commit mess
Hi,
On 4/15/19 10:55 PM, Stefano Stabellini wrote:
On Mon, 18 Feb 2019, Julien Grall wrote:
mfn_to_pdx adds more safety than pfn_to_pdx. Replace all but on place in
the Arm code to use the former.
This is good but maybe we can go even further.
You should also be able to replace one call site
On Mon, 18 Feb 2019, Julien Grall wrote:
> No functional changes.
>
> Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
> ---
> xen/arch/x86/tboot.c | 2 +-
> xen/common/page_alloc.c | 2 +-
> xen/include/asm-arm/mm.h | 4 ++--
> xen/include/asm-x86/mm.h | 4 ++--
> 4 files chang
Hi,
On 4/15/19 11:03 PM, Stefano Stabellini wrote:
On Mon, 18 Feb 2019, Julien Grall wrote:
No functional changes intended.
Please list here the changes this patch is making:
- renaming gnttab_shared_gmfn to gnttab_shared_gfn to follow the naming
convention (and others.)
Ok for this but
On Mon, 18 Feb 2019, Julien Grall wrote:
> diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
> index b56018aace..a9c8352b94 100644
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -138,16 +138,16 @@ extern vaddr_t xenheap_virt_start;
> #endif
>
> #ifdef CONF
On Wed, 13 Mar 2019, Jan Beulich wrote:
> > @@ -215,6 +216,9 @@ void __hwdom_init iommu_hwdom_init(struct domain *d)
> > /* Use while-break to avoid compiler warning */
> > while ( iommu_iotlb_flush_all(d, flush_flags) )
> > break;
> > +#else
> > +rc = -ENOSYS
On Mon, 18 Feb 2019, Julien Grall wrote:
> On x86, mfn_to_gmfn can be replaced with mfn_to_gfn. On Arm, there are
> no more call to mfn_to_gmfn, so the helper can be dropped.
>
> At the same time rework a comment in Arm code that does not make sense.
>
> Signed-off-by: Julien Grall
Lovely.
Ack
On Mon, 15 Apr 2019, Julien Grall wrote:
> Hi,
>
> On 4/15/19 10:55 PM, Stefano Stabellini wrote:
> > On Mon, 18 Feb 2019, Julien Grall wrote:
> > > mfn_to_pdx adds more safety than pfn_to_pdx. Replace all but on place in
> > > the Arm code to use the former.
> >
> > This is good but maybe we can
ref: from chat in #xen
[08:53] pgnd: would be good to send an email so we can keep
track of this in a more formal way.
I've got Xen PV Dom0 booted on a Linux UEFI box
dmesg | grep -i "xen version"
[1.185996] Xen version: 4.12.0_09-lp150.640 (preserve-AD)
flight 134834 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134834/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
Hi,
On 4/15/19 11:25 PM, Stefano Stabellini wrote:
On Mon, 15 Apr 2019, Julien Grall wrote:
Hi,
On 4/15/19 10:55 PM, Stefano Stabellini wrote:
On Mon, 18 Feb 2019, Julien Grall wrote:
mfn_to_pdx adds more safety than pfn_to_pdx. Replace all but on place in
the Arm code to use the former.
T
On Thu, 11 Apr 2019, Christoph Hellwig wrote:
> We can simply loop over the segments and map them, removing lots of
> duplicate code.
Right, the only difference is the additional dma_capable check which is
good to have.
Reviewed-by: Stefano Stabellini
> Signed-off-by: Christoph Hellwig
> ---
On Thu, 11 Apr 2019, Christoph Hellwig wrote:
> Get rid of the grand multiplexer and implement the sync_single_for_cpu
> and sync_single_for_device methods directly, and then loop over them
> for the scatterlist based variants.
>
> Note that this also loses a few comments related to highlevel DMA
On Thu, 11 Apr 2019, Christoph Hellwig wrote:
> Just drop two pointless _attrs prefixes to make the code a little
> more grep-able.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
> ---
> drivers/xen/swiotlb-xen.c | 17 +++--
> 1 file changed, 7 insertions(+),
On Thu, 11 Apr 2019, Christoph Hellwig wrote:
> Refactor the code a bit to make further changes easier.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
> ---
> drivers/xen/swiotlb-xen.c | 31 ---
> 1 file changed, 16 insertions(+), 15 deletions
flight 134823 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134823/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 6 kernel-build fail REGR. vs. 134640
Tests which did not succee
Hello,
https://paste.debian.net/1077718/
I get a kernel panic as shown in the paste above no matter how I
launch pvh, with bootloader (pygrub), kernel direct (4.18+), or
pvgrub2 (i386-xen_pvh support).
The dom0 here is ub1804, kernel-4.18, and xen-4.12 with debian
packages (self built).
~$ sudo
flight 134838 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134838/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
Drop LIST_HEAD where the variable it declares is never used.
The declarations were introduced with the file, but the declared
variables were not used.
Fixes: 1107ba885e469("xen: add xenfs to allow usermode <-> Xen interaction")
Signed-off-by: Mao Wenan
---
drivers/xen/xenbus/xenbus_dev_frontend
On 16/04/2019 06:06, Mao Wenan wrote:
> Drop LIST_HEAD where the variable it declares is never used.
>
> The declarations were introduced with the file, but the declared
> variables were not used.
>
> Fixes: 1107ba885e469("xen: add xenfs to allow usermode <-> Xen interaction")
> Signed-off-by: Ma
flight 134843 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134843/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
flight 134839 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134839/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 6 kernel-build fail REGR. vs. 134640
Tests which did not succee
Hi guys.
Currently Im working with xen source code, tring to include new
functionality; in specifict, Im working with xenoprof. But, I've found
some compilation problems due to the flag #define COMPAT.
here my questions:
What the COMPAT definition does?
Pros and Cons of COMPAT enable/disable?
88 matches
Mail list logo
