On Thu, Dec 27, 2018 at 04:40:55PM +0300, Dan Carpenter wrote:
> On Tue, Dec 25, 2018 at 11:12:20PM +0100, Tom Psyborg wrote:
> > there was discussion about this just some days ago. CC 4-5 lists is
> > more than enough
> >
>
> I don't know who you were discussing this with...
>
> You should CC t
flight 131627 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131627/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 129475
build-i386-xsm
On Fri, 28 Dec 2018, Darrick J. Wong wrote:
> On Thu, Dec 27, 2018 at 04:40:55PM +0300, Dan Carpenter wrote:
> > On Tue, Dec 25, 2018 at 11:12:20PM +0100, Tom Psyborg wrote:
> > > there was discussion about this just some days ago. CC 4-5 lists is
> > > more than enough
> > >
> >
> > I don't kno
flight 131624 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131624/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 129475
build-i386-xsm
flight 131613 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131613/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumprun-amd64 7 xen-boot fail REGR. vs. 125898
test-amd64-amd64-am
Extend the framework to support (simple) monitor related tests.
Changes from v1:
- Refactored the monitor test (cleanup)
- Replace the "emul-unimplemented" test with a simpler mem_access test
Petre Pircalabu (4):
xtf-runner: split into logical components
xtf: Add executable test class
xtf:
This class starts alongside the domain a monitor application which opens
an event channel corresponding to that domain and handles the received
requests.
Use the "monitor_args" key to pass test specific arguments to the
monitor application.
The arguments will be added in the test's Makefile using t
The Executable test class runs on host (dom0). The class spawns a
process and searches the program output(stdio) for a specific pattern.
Signed-off-by: Petre Pircalabu
---
xtf/__init__.py| 2 +-
xtf/executable_test.py | 83 ++
xtf/suite.py
Split the xtf-runner script file into multiple modules in order to
support multiple test types.
Features:
- 2 abstract types (TestInfo and TestInstance) to represent the
test information (info.json) and, respectively to implement the test
execution.
TestInfo has to implement the "all_ins
The monitor application resets the execute permisions on a specific page
of the DOMU and handles the generated vm_event request.
Signed-off-by: Petre Pircalabu
---
docs/all-tests.dox | 1 +
tests/monitor-mem-access/Makefile | 14
tests/monitor-mem-access/main.c| 37
flight 131623 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131623/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On 06/12/2018 10:59, Jan Beulich wrote:
On 03.12.18 at 17:18, wrote:
>> --- a/xen/include/asm-x86/cpufeatures.h
>> +++ b/xen/include/asm-x86/cpufeatures.h
>> @@ -25,6 +25,7 @@ XEN_CPUFEATURE(XEN_SMAP,(FSCAPINTS+0)*32+11) /*
>> SMAP gets used by Xen it
>> XEN_CPUFEATURE(LFENCE_DISPAT
On 28/12/2018 15:46, Pu Wen wrote:
> On 2018/12/28 5:11, Andrew Cooper wrote:
>> On 26/12/2018 11:42, Pu Wen wrote:
>>> On 2018/12/21 18:20, Andrew Cooper wrote:
Is there anything which is actually unique to Hygon here? I ask,
because this looks like a lot of duplicate code, considering
On 28/12/2018 15:14, Roger Pau Monné wrote:
> On Fri, Dec 28, 2018 at 12:39:31PM +, Andrew Cooper wrote:
>> This reduces the complexity of init_amd(), and collects related
>> workarounds together.
>>
>> It also offers us the opportunity to stop performing workarounds when
>> virtualised - doing
On 28/12/2018 15:43, Roger Pau Monné wrote:
> On Fri, Dec 28, 2018 at 12:39:35PM +, Andrew Cooper wrote:
>> AMD hardware before Zen doesn't safe/restore the FPU error pointers
>> unless an unmasked FPU exception is pending. Zen processors have a
>> feature bit indicating that this (mis)behavio
On 28/12/2018 15:26, Roger Pau Monné wrote:
> On Fri, Dec 28, 2018 at 12:39:33PM +, Andrew Cooper wrote:
>> There are multiple problems:
>>
>> * The opt_allow_unsafe < 0 logic is dead since 2012 (c/s 0c7a6966511
>>"x86-64: refine the XSA-9 fix").
>> * Given that opt_allow_unsafe was delib
On Fri, Dec 28, 2018 at 02:58:49PM +, Andrew Cooper wrote:
> On 28/12/2018 12:04, Roger Pau Monne wrote:
> > Hello,
> >
> > This series includes some miscellaneous fixes for the pv-shim mode,
> > specially regarding the handling of the memory map.
>
> Unfortunately, something overall is now wo
On Fri, Dec 28, 2018 at 12:39:36PM +, Andrew Cooper wrote:
> c/s fd32dcfe4c "x86/vmx: Don't leak EFER.NXE into guest context" had an
> unintended consequence on Harpertown cores which, as it turns out, don't
> load MSR_EFER fully from the MSR Load List - on reentry to the guest,
> EFER.SCE is c
On 2018/12/28 5:11, Andrew Cooper wrote:
> On 26/12/2018 11:42, Pu Wen wrote:
>> On 2018/12/21 18:20, Andrew Cooper wrote:
>>> Is there anything which is actually unique to Hygon here? I ask,
>>> because this looks like a lot of duplicate code, considering that the
>>> processor base is the same.
flight 131620 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131620/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 129475
build-i386-xsm
On Fri, Dec 28, 2018 at 12:39:35PM +, Andrew Cooper wrote:
> AMD hardware before Zen doesn't safe/restore the FPU error pointers
> unless an unmasked FPU exception is pending. Zen processors have a
> feature bit indicating that this (mis)behaviour no longer exists.
>
> Express the common logi
On Fri, Dec 28, 2018 at 12:39:34PM +, Andrew Cooper wrote:
> AMD processors don't clear the base or limit fields when loading a NULL
> segment, and Hygon processors inherit this behaviour.
>
> Express the logic in terms of cpu_bug_null_seg, and rearrange
> preload_segment() have the more predi
On Fri, Dec 28, 2018 at 12:39:33PM +, Andrew Cooper wrote:
> There are multiple problems:
>
> * The opt_allow_unsafe < 0 logic is dead since 2012 (c/s 0c7a6966511
>"x86-64: refine the XSA-9 fix").
> * Given that opt_allow_unsafe was deliberately intended not to be
>specific to #121 a
On Fri, Dec 28, 2018 at 12:39:32PM +, Andrew Cooper wrote:
> Future changes are going to want to use cpu_bug_* in a mannor similar to
> Linux. Introduce one bug word, and generalise the calculation of
> NCAPINTS.
>
> Signed-off-by: Andrew Cooper
Should the commit message also note the intro
On Fri, Dec 28, 2018 at 12:39:31PM +, Andrew Cooper wrote:
> This reduces the complexity of init_amd(), and collects related
> workarounds together.
>
> It also offers us the opportunity to stop performing workarounds when
> virtualised - doing so is wasteful, as it all involves poking MSRs wh
On 28/12/2018 12:04, Roger Pau Monne wrote:
> Hello,
>
> This series includes some miscellaneous fixes for the pv-shim mode,
> specially regarding the handling of the memory map.
Unfortunately, something overall is now wonky. With this series
applied, I'm getting:
(d9) (XEN) Initial PVH-e820 RAM
On 12/28/18 11:15 AM, Juergen Gross wrote:
> On 27/12/2018 22:12, Hans van Kranenburg wrote:
>> So,
>>
>> On 12/24/18 1:32 AM, Hans van Kranenburg wrote:
>>>
>>> On 12/21/18 6:54 PM, Hans van Kranenburg wrote:
We've been tracking down a live migration bug during the last three days
h
flight 131599 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131599/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 129313
test-amd64-amd64-xl-
On 28/12/2018 11:18, Roger Pau Monne wrote:
> Current code that allocates memory and populates the p2m for PVH Dom0
> doesn't take the address alignment into account, this can lead to high
> order allocations that start on a non-aligned address to be broken
> down into lower order entries on the p2
flight 131617 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131617/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd a85bc55a7f565e903359e12dbd8a90dcf962473e
baseline version:
freebsd 5234db76104
There are multiple problems:
* The opt_allow_unsafe < 0 logic is dead since 2012 (c/s 0c7a6966511
"x86-64: refine the XSA-9 fix").
* Given that opt_allow_unsafe was deliberately intended not to be
specific to #121 alone, setting it to true for the not-affected case
will cause a security
AMD hardware before Zen doesn't safe/restore the FPU error pointers
unless an unmasked FPU exception is pending. Zen processors have a
feature bit indicating that this (mis)behaviour no longer exists.
Express the common logic in terms of cpu_bug_fpu_err_ptr as Hygon
processors (being Zen derivati
AMD processors don't clear the base or limit fields when loading a NULL
segment, and Hygon processors inherit this behaviour.
Express the logic in terms of cpu_bug_null_seg, and rearrange
preload_segment() have the more predictable condition first, not
reference AMD specifically.
Tweak the inline
This series borrows the cpu_bug_* idea from Linux. Using that, it reworks
some of the AMD issues which impact the ongoing effort to upstream Hygon CPU
support, and it works around the Harpertown SCE issue which breaks 64bit HVM
guests.
Andrew Cooper (6):
x86/AMD Split init_amd() into per-uarch
Future changes are going to want to use cpu_bug_* in a mannor similar to
Linux. Introduce one bug word, and generalise the calculation of
NCAPINTS.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/include/asm-x86/cpufeatures.h | 57
This reduces the complexity of init_amd(), and collects related
workarounds together.
It also offers us the opportunity to stop performing workarounds when
virtualised - doing so is wasteful, as it all involves poking MSRs which
no hypervisor will let us touch in practice.
As amd.c has diverged a
c/s fd32dcfe4c "x86/vmx: Don't leak EFER.NXE into guest context" had an
unintended consequence on Harpertown cores which, as it turns out, don't
load MSR_EFER fully from the MSR Load List - on reentry to the guest,
EFER.SCE is clear irrespective of the value in load list.
This, being catastrophic
When running Xen as a guest it's not necessary to mark such pages as
RAM because they won't be assigned to the initial domain memory map.
While there move the functions to the PV shim specific file and rename
them accordingly.
No functional change expected.
Reported-by: Andrew Cooper
Signed-off
This implies there's no need to forcefully reserve the VGA MMIO
region, since the memory map provided will be correct.
Reported-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
Changes since v1:
- Assume the memory map is always correct w
This function is based on the Linux e820__range_remove function,
adjusted to fit Xen.
Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
Changes since v1:
- Fix one coding style issue.
---
xen/arch/x86/e820.c| 57
And instead use the newly introduced e820_remove_range helper to
remove any RAM region from the low 1MB VGA/ROM region afterwards.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
xen/arch/x86/e820.c | 26
Hello,
This series includes some miscellaneous fixes for the pv-shim mode,
specially regarding the handling of the memory map.
It can be found on my git branch:
git://xenbits.xen.org/people/royger/xen.git guest-fixes-v2
Thanks, Roger.
Roger Pau Monne (4):
x86/e820: introduce a function to re
On Thu, Dec 27, 2018 at 09:03:00PM +, Andrew Cooper wrote:
> On 27/12/2018 15:56, Roger Pau Monne wrote:
> > This implies there's no need to forcefully reserve the VGA MMIO
> > region, since the memory map provided will be correct.
> >
> > Reported-by: Andrew Cooper
> > Signed-off-by: Roger Pa
Add a verbose option to the dom0 command line, so that dom0 builder
can print extra debug information when required.
Use this new verbose mode to print statistics about memory allocations
when populating dom0 p2m.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian J
Hello,
This series contains an improvement when filling the p2m so that
alignment is taken into account when allocating and populating the p2m.
The last patch is optional and adds a verbose mode to dom0 build so more
information can be printed.
Thanks, Roger.
Roger Pau Monne (2):
x86/dom0: ta
Current code that allocates memory and populates the p2m for PVH Dom0
doesn't take the address alignment into account, this can lead to high
order allocations that start on a non-aligned address to be broken
down into lower order entries on the p2m page tables.
Fix this by taking into account the
On Thu, Dec 27, 2018 at 08:14:40PM +, Andrew Cooper wrote:
> On 27/12/2018 15:26, Roger Pau Monne wrote:
> > Current code that allocates memory and populates the p2m for PVH Dom0
> > doesn't take the address alignment into account, this can lead to high
> > order allocations that start on a non
flight 131593 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131593/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 128858
test-amd64-i386-qemu
flight 131615 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131615/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 129475
build-i386-xsm
On 27/12/2018 22:12, Hans van Kranenburg wrote:
> So,
>
> On 12/24/18 1:32 AM, Hans van Kranenburg wrote:
>>
>> On 12/21/18 6:54 PM, Hans van Kranenburg wrote:
>>>
>>> We've been tracking down a live migration bug during the last three days
>>> here at work, and here's what we found so far.
>>>
>>
flight 131595 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131595/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail like 131583
test-amd64-amd64-xl-qemut-win7-amd64
flight 131614 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131614/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 129475
build-i386-xsm
On 28.12.18 10:28, Andrii Anisov wrote:
Please give me some time to find the instruction to update bootloaders on ulcb.
Here is the instruction for h3ulcb to flash the firmware for Yocto 2.19 [1].
Yet it is quite old.
[1] https://elinux.org/index.php?title=R-Car/Boards/H3SK&oldid=449556
--
On 28.12.18 10:28, Andrii Anisov wrote:
Hello Jairo,
This is just a quick reply.
On 28.12.18 17:22, LOPEZ, FUENTES NACARINO Jairo Eduardo wrote:
Via serial console I get the following output for the images created after
modifying the dts and applying the patch below:
U-Boot 2015.04 (Jun 22
Hello Jairo,
This is just a quick reply.
On 28.12.18 17:22, LOPEZ, FUENTES NACARINO Jairo Eduardo wrote:
Via serial console I get the following output for the images created after
modifying the dts and applying the patch below:
U-Boot 2015.04 (Jun 22 2018 - 13:36:27)
I see, you did not upda
Hello Andrii and everyone still listening,
I am sorry for sending attachments to the mailing list. Below is my github
with the patch I applied and the dts I made to attempt to boot the R-Car H3.
https://github.com/nacarino/xen-arm
As Andrii suggested, I attempted only compiling Xen with the SRCR
56 matches
Mail list logo
