[Xen-devel] [qemu-mainline test] 112869: tolerable trouble: blocked/broken/fail/pass - PUSHED

flight 112869 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/112869/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1

[Xen-devel] [linux-3.18 test] 112868: trouble: blocked/broken/fail/pass

flight 112868 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/112868/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 3 capture-logs broken REGR. vs. 112102

[Xen-devel] [xen-unstable-smoke test] 112879: tolerable trouble: broken/pass - PUSHED

flight 112879 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/112879/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-pvops 2

[Xen-devel] [ovmf baseline-only test] 72024: all pass

This run is configured for baseline tests only. flight 72024 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72024/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 02739b0f41300da70369be7c1982180306e8ca95 baseline

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

flight 112877 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/112877/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 112875 Tests which

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

flight 112865 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/112865/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 112809

[Xen-devel] [xen-unstable-smoke test] 112875: tolerable trouble: broken/pass - PUSHED

flight 112875 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/112875/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-pvops 2

[Xen-devel] [ovmf test] 112867: all pass - PUSHED

flight 112867 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/112867/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 02739b0f41300da70369be7c1982180306e8ca95 baseline version: ovmf

[Xen-devel] [libvirt test] 112866: tolerable trouble: blocked/broken/pass - PUSHED

flight 112866 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/112866/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1

Re: [Xen-devel] [RFC PATCH v1 2/7] iommu/arm: ipmmu-vmsa: Add Xen changes for main driver

On Wed, 23 Aug 2017, Julien Grall wrote: > Hi Oleksandr, > > On 21/08/17 16:53, Oleksandr Tyshchenko wrote: > > On Thu, Aug 10, 2017 at 6:13 PM, Julien Grall wrote: > > > On 10/08/17 15:27, Oleksandr Tyshchenko wrote: > > > > I would like to clarify what need to be done

[Xen-devel] [linux-linus test] 112864: regressions - trouble: blocked/broken/fail/pass

flight 112864 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/112864/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-saverestore.2 fail REGR. vs. 110515

Re: [Xen-devel] [Qemu-devel] [PATCH 4/5] pci: Add INTERFACE_LEGACY_PCI_DEVICE to legacy PCI devices

CCing maintainers of affected devices (sorry for not CCing you before). On Wed, Aug 23, 2017 at 07:14:44PM -0300, Eduardo Habkost wrote: > Add INTERFACE_LEGACY_PCI_DEVICE to all direct subtypes of > TYPE_PCI_DEVICE, except: > > 1) The ones that already have INTERFACE_PCIE_DEVICE set: > > *

Re: [Xen-devel] [PATCH] xen: fix parse_bool() with empty string

On 25/08/17 17:15, Wei Liu wrote: > On Fri, Aug 25, 2017 at 06:11:25PM +0200, Juergen Gross wrote: >> parse_bool() should return -1 in case it is called with an empty >> string. In order to allow boolean parameters in the cmdline without >> specifying a value this case must be handled in

Re: [Xen-devel] [PATCH] common/gnttab: Introduce command line feature controls

On 25/08/17 18:36, Juergen Gross wrote: > On 25/08/17 18:21, George Dunlap wrote: >> On 08/25/2017 01:31 PM, Jan Beulich wrote: >> On 25.08.17 at 14:10, wrote: On 25/08/17 10:57, Jan Beulich wrote: On 24.08.17 at 17:16,

Re: [Xen-devel] [PATCH v5 3/3] tools/libxc: use superpages during restore of HVM guest

On Fri, Aug 25, Olaf Hering wrote: > +static int x86_hvm_populate_pfns(struct xc_sr_context *ctx, unsigned count, > + const xen_pfn_t *original_pfns, > + const uint32_t *types) > +{ > +while ( min_pfn < max_pfn ) Beside this

Re: [Xen-devel] [PATCH v3] hvmloader, libxl: use the correct ACPI settings depending on device model

On Thu, Aug 17, 2017 at 03:57:13PM +0100, Igor Druzhinin wrote: > We need to choose ACPI tables and ACPI IO port location > properly depending on the device model version we are running. > Previously, this decision was made by BIOS type specific > code in hvmloader, e.g. always load QEMU

Re: [Xen-devel] [PATCH 11/14] fuzz/x86_emulate: Make input more compact

On 25/08/17 17:43, George Dunlap wrote: > At the moment, AFL reckons that for any given input, 87% of it is > completely irrelevant: that is, it can change it as much as it wants > but have no impact on the result of the test; and yet it can't remove > it. > > This is largely because we interpret

Re: [Xen-devel] [PATCH 06/14] fuzz/x86_emulate: Implement dread() and davail()

On 25/08/17 17:43, George Dunlap wrote: > Rather than open-coding the "read" from the input file. > > Signed-off-by: George Dunlap This patch fills me with dread. How about data_read() and data_available() which are slightly more descriptive? Also, both should be

Re: [Xen-devel] [PATCH 04/14] fuzz/x86_emulate: Add a better input size check

On 25/08/17 17:43, George Dunlap wrote: > For some reason the 'feof()' check for the file size isn't working in > llvm-clang-fast mode; the result is several kilobyte files rather than > the 4k limit files as we've requested. This is bad in part because > AFL will spend time trying to "fuzz" bits

Re: [Xen-devel] [PATCH 01/14] fuzz/x86_emulate: Remove redundant AFL hook

On 25/08/17 17:43, George Dunlap wrote: > You don't need __AFL_INIT if you have __AFL_LOOP. > > Signed-off-by: George Dunlap Really? Is that covered in any documentation? I got the contrary impression from whichever version of AFL I was using when I put this in, and a

Re: [Xen-devel] [PATCH] common/gnttab: Introduce command line feature controls

On 25/08/17 18:21, George Dunlap wrote: > On 08/25/2017 01:31 PM, Jan Beulich wrote: > On 25.08.17 at 14:10, wrote: >>> On 25/08/17 10:57, Jan Beulich wrote: >>> On 24.08.17 at 17:16, wrote: > On 24/08/17 16:01, Juergen Gross

Re: [Xen-devel] [PATCH v2] xen: Emit RTC_CHANGE upon TIMEOFFSET ioreq

On Wed, 23 Aug 2017, Ross Lagerwall wrote: > When the guest writes to the RTC, Xen emulates it and broadcasts a > TIMEOFFSET ioreq. Emit an RTC_CHANGE QMP event to all QMP monitors when > this happens rather than ignoring it so that something useful can be > done with the information. This is the

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

On 08/25/2017 09:40 AM, Jan Beulich wrote: On 25.08.17 at 05:15, wrote: >> flight 112855 xen-unstable real [real] >> http://logs.test-lab.xenproject.org/osstest/logs/112855/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, >> including

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

flight 112874 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/112874/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 4 host-install(4)broken REGR.

[Xen-devel] [PATCH 14/14] fuzz/x86_emulate: Add an option to limit the number of instructions executed

AFL considers a testcase to be a useful addition not only if there are tuples exercised by that testcase which were not exercised otherwise, but also if the *number* of times an individual tuple is exercised changes significantly; in particular, if the number of the highes bit changes (i.e., if it

[Xen-devel] [PATCH 12/14] fuzz/x86_emulate: Add --rerun option to try to track down instability

Current stability numbers are not 100%. In order to help track this down, add a --rerun option which will run the same input twice, resetting the state in between each run, and comparing the state afterwards. If the state differs, call abort(). This allows AFL to help the process of tracking

[Xen-devel] [PATCH 11/14] fuzz/x86_emulate: Make input more compact

At the moment, AFL reckons that for any given input, 87% of it is completely irrelevant: that is, it can change it as much as it wants but have no impact on the result of the test; and yet it can't remove it. This is largely because we interpret the blob handed to us as a large struct, including

[Xen-devel] [PATCH 13/14] fuzz/x86_emulate: Set and fuzz more CPU state

x86_emulate() operates not only on state passed to it in cpu_user_regs, but also on state currently found on the cpu: namely, the FPU and XMM registers. At the moment, we re-zero (and/or re-initialize) cpu_user_regs on every invocation, but leave the cpu-stored state alone. In "persistent mode",

[Xen-devel] [PATCH 05/14] fuzz/x86_emulate: Improve failure descriptions in x86_emulate harness

- Print the symbolic name rather than the number - Explicitly state when data_read() fails due to EOI Signed-off-by: George Dunlap --- CC: Ian Jackson CC: Wei Liu CC: Andrew Cooper CC: Jan

[Xen-devel] [PATCH 10/14] fuzz/x86_emulate: Move all state into fuzz_state

This is in preparation for adding the option for a more "compact" interpretation of the fuzzing data, in which we only change select bits of the state. Signed-off-by: George Dunlap --- tools/fuzz/x86_instruction_emulator/fuzz-emul.c | 90 + 1

[Xen-devel] [PATCH 02/14] x86emul/fuzz: add rudimentary limit checking

From: Jan Beulich fuzz_insn_fetch() is the only data access helper where it is possible to see offsets larger than 4Gb in 16- or 32-bit modes, as we leave the incoming rIP untouched in the emulator itself. The check is needed here as otherwise, after successfully fetching insn

[Xen-devel] [PATCH 08/14] fuzz/x86_emulate: Add 'afl-cov' target

...to generate a "normal" coverage-instrumented binary, suitable for use with gcov or afl-cov. This is slightly annoying because: - Every object file needs to have been instrumented to work effectively - You generally want to have both an afl-instrumented binary and a gcov-instrumented

[Xen-devel] [PATCH 03/14] fuzz/x86_emulate: Actually use cpu_regs input

Commit c07574b reorganized the way fuzzing was done, explicitly creating a structure that the input data would be copied into. Unfortunately, the cpu register state used by the emulator is on the stack; it's cleared, but data is never copied into it. If we're explicitly setting an entirely new

[Xen-devel] [PATCH 07/14] fuzz/x86_emulate: Rename the file containing the wrapper code

When generating coverage output, by default gcov generates output filenames based only on the coverage file and the "leaf" source file, not the full path. As a result, it uses the same name for x86_emulate.c and x86_emulate/x86_emulate.c, generally overwriting the second (which we actually are

[Xen-devel] [PATCH 06/14] fuzz/x86_emulate: Implement dread() and davail()

Rather than open-coding the "read" from the input file. Signed-off-by: George Dunlap --- CC: Ian Jackson CC: Wei Liu CC: Andrew Cooper CC: Jan Beulich ---

[Xen-devel] [PATCH 01/14] fuzz/x86_emulate: Remove redundant AFL hook

You don't need __AFL_INIT if you have __AFL_LOOP. Signed-off-by: George Dunlap --- CC: Ian Jackson CC: Wei Liu CC: Andrew Cooper CC: Jan Beulich ---

[Xen-devel] [PATCH 04/14] fuzz/x86_emulate: Add a better input size check

For some reason the 'feof()' check for the file size isn't working in llvm-clang-fast mode; the result is several kilobyte files rather than the 4k limit files as we've requested. This is bad in part because AFL will spend time trying to "fuzz" bits of the input that are never touched. Add a new

[Xen-devel] [PATCH 09/14] fuzz/x86_emulate: Take multiple test files for inputs

Finding aggregate coverage for a set of test files means running each afl-generated test case through the harness. At the moment, this is done by re-executing afl-harness-cov with each input file. When a large number of test cases have been generated, this can take a significant amonut of time;

[Xen-devel] [PATCH v5 0/3] tools/libxc: use superpages

Using superpages on the receiving dom0 will avoid performance regressions. Olaf v5: send correct version, rebase was not fully finished v4: restore trailing "_bit" in bitmap function names keep track of gaps between previous and current batch split alloc functionality in x86_hvm_allocate_pfn

[Xen-devel] [PATCH v5 3/3] tools/libxc: use superpages during restore of HVM guest

During creating of a HVM domU meminit_hvm() tries to map superpages. After save/restore or migration this mapping is lost, everything is allocated in single pages. This causes a performance degradition after migration. Add neccessary code to preallocate a superpage for the chunk of pfns that is

[Xen-devel] [PATCH v5 2/3] tools/libxc: add API for bitmap access for restore

Extend API for managing bitmaps. Each bitmap is now represented by a generic struct xc_sr_bitmap. Switch the existing populated_pfns to this API. Signed-off-by: Olaf Hering Acked-by: Wei Liu --- tools/libxc/xc_sr_common.c | 41 +++

[Xen-devel] [PATCH v5 1/3] tools/libxc: move SUPERPAGE macros to common header

The macros SUPERPAGE_2MB_SHIFT and SUPERPAGE_1GB_SHIFT will be used by other code in libxc. Move the macros to a header file. Signed-off-by: Olaf Hering Acked-by: Wei Liu --- tools/libxc/xc_dom_x86.c | 5 - tools/libxc/xc_private.h | 5 + 2 files

[Xen-devel] [PATCH v4 2/3] tools/libxc: add API for bitmap access for restore

Extend API for managing bitmaps. Each bitmap is now represented by a generic struct xc_sr_bitmap. Switch the existing populated_pfns to this API. Signed-off-by: Olaf Hering Acked-by: Wei Liu --- tools/libxc/xc_sr_common.c | 41 +++

[Xen-devel] [PATCH v4 3/3] tools/libxc: use superpages during restore of HVM guest

During creating of a HVM domU meminit_hvm() tries to map superpages. After save/restore or migration this mapping is lost, everything is allocated in single pages. This causes a performance degradition after migration. Add neccessary code to preallocate a superpage for the chunk of pfns that is

[Xen-devel] [PATCH v4 0/3] tools/libxc: use superpages

Using superpages on the receiving dom0 will avoid performance regressions. Olaf v4: restore trailing "_bit" in bitmap function names keep track of gaps between previous and current batch split alloc functionality in x86_hvm_allocate_pfn v3: clear pointer in xc_sr_bitmap_free some coding

[Xen-devel] [PATCH v4 1/3] tools/libxc: move SUPERPAGE macros to common header

The macros SUPERPAGE_2MB_SHIFT and SUPERPAGE_1GB_SHIFT will be used by other code in libxc. Move the macros to a header file. Signed-off-by: Olaf Hering Acked-by: Wei Liu --- tools/libxc/xc_dom_x86.c | 5 - tools/libxc/xc_private.h | 5 + 2 files

Re: [Xen-devel] [PATCH] common/gnttab: Introduce command line feature controls

On 08/25/2017 01:31 PM, Jan Beulich wrote: On 25.08.17 at 14:10, wrote: >> On 25/08/17 10:57, Jan Beulich wrote: >> On 24.08.17 at 17:16, wrote: On 24/08/17 16:01, Juergen Gross wrote: > On 24/08/17 16:50, Andrew Cooper

Re: [Xen-devel] [PATCH] xen: fix parse_bool() with empty string

On Fri, Aug 25, 2017 at 06:11:25PM +0200, Juergen Gross wrote: > parse_bool() should return -1 in case it is called with an empty > string. In order to allow boolean parameters in the cmdline without > specifying a value this case must be handled in _cmdline_parse() by > always passing a value

[Xen-devel] [PATCH] xen: fix parse_bool() with empty string

parse_bool() should return -1 in case it is called with an empty string. In order to allow boolean parameters in the cmdline without specifying a value this case must be handled in _cmdline_parse() by always passing a value string. This fixes commit 532dec8e31174ed450adfd36a4b0b41dec27010d ("xen:

Re: [Xen-devel] [PATCH v3] passthrough: give XEN_DOMCTL_test_assign_device more sane semantics (and 1 more message)

On Fri, Aug 25, 2017 at 09:54:18AM -0600, Jan Beulich wrote: > >>> On 25.08.17 at 17:25, wrote: > > On Wed, Aug 16, 2017 at 06:20:01AM -0600, Jan Beulich wrote: > >> So far callers of the libxc interface passed in a domain ID which was > >> then ignored in the hypervisor.

[Xen-devel] [linux-4.9 test] 112863: tolerable trouble: blocked/broken/fail/pass - PUSHED

flight 112863 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/112863/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 12 guest-start fail REGR. vs. 112672 Tests which did not succeed,

Re: [Xen-devel] [PATCH v3] passthrough: give XEN_DOMCTL_test_assign_device more sane semantics

>>> On 25.08.17 at 17:54, wrote: On 25.08.17 at 17:25, wrote: >> On Wed, Aug 16, 2017 at 06:20:01AM -0600, Jan Beulich wrote: >>> So far callers of the libxc interface passed in a domain ID which was >>> then ignored in the hypervisor. Instead, make

Re: [Xen-devel] [PATCH v2] x86/apic/x2apic: Share IRQ vector between cluster members only when no cpumask is specified

On 08/25/2017 10:56 AM, Jan Beulich wrote: On 08.08.17 at 17:59, wrote: >> --- a/xen/arch/x86/genapic/delivery.c >> +++ b/xen/arch/x86/genapic/delivery.c >> @@ -30,7 +30,8 @@ void __init clustered_apic_check_flat(void) >> printk("Enabling APIC mode: Flat.

Re: [Xen-devel] [PATCH v6] x86/hvm: Allow guest_request vm_events coming from userspace

>>> On 25.08.17 at 17:49, wrote: > On 08/25/2017 02:44 PM, Jan Beulich wrote: > On 25.08.17 at 15:00, wrote: >>> On Vi, 2017-08-25 at 06:13 -0600, Jan Beulich wrote: > >> >>> >>> On 17.08.17 at 13:50,

Re: [Xen-devel] [PATCH v3] passthrough: give XEN_DOMCTL_test_assign_device more sane semantics

>>> On 25.08.17 at 17:25, wrote: > On Wed, Aug 16, 2017 at 06:20:01AM -0600, Jan Beulich wrote: >> So far callers of the libxc interface passed in a domain ID which was >> then ignored in the hypervisor. Instead, make the hypervisor honor it >> (accepting DOMID_INVALID to

Re: [Xen-devel] [PATCH v6] x86/hvm: Allow guest_request vm_events coming from userspace

On 08/25/2017 02:44 PM, Jan Beulich wrote: On 25.08.17 at 15:00, wrote: >> On Vi, 2017-08-25 at 06:13 -0600, Jan Beulich wrote: > >> >> On 17.08.17 at 13:50, wrote: --- a/xen/common/monitor.c +++

Re: [Xen-devel] [kernel-hardening] Re: x86: PIE support and option to extend KASLR randomization

On Thu, 17 Aug 2017, Boris Lukashev wrote: > Is the expectation then to have security functions also decrease size > and operational latency? Seems a bit unrealistic if so. > 1-2% performance hit on systems which have become at least several > hundred % faster over recent years is not a

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Thu, Aug 24, 2017 at 2:42 PM, Linus Torvalds wrote: > > On Thu, Aug 24, 2017 at 2:13 PM, Thomas Garnier wrote: > > > > My original performance testing was done with an Ubuntu generic > > configuration. This configuration has the

Re: [Xen-devel] [PATCH RESEND v9] VT-d: use correct BDF for VF to search VT-d unit

On Fri, Aug 25, 2017 at 09:20:23AM -0600, Jan Beulich wrote: On 25.08.17 at 15:51, wrote: >> On Fri, Aug 25, 2017 at 03:39:38AM -0600, Jan Beulich wrote: >> On 25.08.17 at 07:27, wrote: When SR-IOV is enabled, 'Virtual Functions' of a

Re: [Xen-devel] [PATCH v6] x86/hvm: Allow guest_request vm_events coming from userspace

On Fri, Aug 25, 2017 at 7:44 AM, Jan Beulich wrote: On 25.08.17 at 15:00, wrote: >> On Vi, 2017-08-25 at 06:13 -0600, Jan Beulich wrote: >>> > >>> > > >>> > > > >>> > > > On 17.08.17 at 13:50, wrote: >>> > ---

Re: [Xen-devel] [PATCH v3] passthrough: give XEN_DOMCTL_test_assign_device more sane semantics

On Wed, Aug 16, 2017 at 06:20:01AM -0600, Jan Beulich wrote: > So far callers of the libxc interface passed in a domain ID which was > then ignored in the hypervisor. Instead, make the hypervisor honor it > (accepting DOMID_INVALID to obtain original behavior), allowing to > query whether a device

Re: [Xen-devel] [PATCH] x86/pv: Minor improvements to guest_get_eff_{, kern}_l1e()

On 24/08/17 13:35, Jan Beulich wrote: On 24.08.17 at 13:13, wrote: >> On 24/08/17 09:44, Jan Beulich wrote: >>> >>> On 23.08.17 at 21:09, wrote: * These functions work in terms of linear addresses, not virtual addresses.

Re: [Xen-devel] [PATCH RESEND v9] VT-d: use correct BDF for VF to search VT-d unit

>>> On 25.08.17 at 15:51, wrote: > On Fri, Aug 25, 2017 at 03:39:38AM -0600, Jan Beulich wrote: > On 25.08.17 at 07:27, wrote: >>> When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function' are >>> under >>> the scope of the same VT-d unit

Re: [Xen-devel] [PATCH 3/3] x86/mm: Introduce and use l?e_{get, from}_mfn()

On 25/08/17 16:03, George Dunlap wrote: > On 08/25/2017 04:00 PM, George Dunlap wrote: >> On 08/24/2017 02:14 PM, Andrew Cooper wrote: >>> This avoids the explicit boxing/unboxing of mfn_t in relevant codepaths. >>> >>> Signed-off-by: Andrew Cooper >> [snip] >> >>> diff

Re: [Xen-devel] [PATCH] tools/hvmloader: Use base instead of pci_mem_start for find_next_rmrr()

>>> On 21.08.17 at 23:53, wrote: > @@ -464,15 +462,19 @@ void pci_setup(void) > base = (resource->base + bar_sz - 1) & ~(uint64_t)(bar_sz - 1); > > /* If we're using mem_resource, check for RMRR conflicts. */ > -while ( resource == _resource

Re: [Xen-devel] [PATCH 3/3] x86/mm: Introduce and use l?e_{get, from}_mfn()

On 08/24/2017 02:14 PM, Andrew Cooper wrote: > This avoids the explicit boxing/unboxing of mfn_t in relevant codepaths. > > Signed-off-by: Andrew Cooper Acked-by: George Dunlap ___ Xen-devel

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Fri, Aug 25, 2017 at 1:04 AM, Ingo Molnar wrote: > > * Thomas Garnier wrote: > >> With the fix for function tracing, the hackbench results have an >> average of +0.8 to +1.4% (from +8% to +10% before). With a default >> configuration, the numbers are

Re: [Xen-devel] [PATCH 3/3] x86/mm: Introduce and use l?e_{get, from}_mfn()

On 08/25/2017 04:00 PM, George Dunlap wrote: > On 08/24/2017 02:14 PM, Andrew Cooper wrote: >> This avoids the explicit boxing/unboxing of mfn_t in relevant codepaths. >> >> Signed-off-by: Andrew Cooper > > [snip] > >> diff --git a/xen/include/asm-x86/page.h

Re: [Xen-devel] [PATCH 3/3] x86/mm: Introduce and use l?e_{get, from}_mfn()

On 08/24/2017 02:14 PM, Andrew Cooper wrote: > This avoids the explicit boxing/unboxing of mfn_t in relevant codepaths. > > Signed-off-by: Andrew Cooper [snip] > diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h > index 242903f..8463d71 100644 >

[Xen-devel] Ping#2: [PATCH v3] x86/HVM: don't #GP/#SS on wrapping virt->linear translations

>>> On 10.08.17 at 09:19, wrote: On 10.07.17 at 12:39, wrote: >> Real hardware wraps silently in most cases, so we should behave the >> same. Also split real and VM86 mode handling, as the latter really >> ought to have limit checks applied. >> >>

[Xen-devel] Ping: [PATCH v3] passthrough: give XEN_DOMCTL_test_assign_device more sane semantics

>>> On 16.08.17 at 14:20, wrote: > So far callers of the libxc interface passed in a domain ID which was > then ignored in the hypervisor. Instead, make the hypervisor honor it > (accepting DOMID_INVALID to obtain original behavior), allowing to > query whether a device can be

Re: [Xen-devel] [PATCH 2/3] x86/mm: Replace opencoded forms of map_l?t_from_l?e()

On 08/24/2017 02:14 PM, Andrew Cooper wrote: > No functional change (confirmed by diffing the disassembly). > > Signed-off-by: Andrew Cooper Reviewed-by: George Dunlap > --- > CC: Jan Beulich > CC: Wei Liu

Re: [Xen-devel] [PATCH v2] x86/apic/x2apic: Share IRQ vector between cluster members only when no cpumask is specified

>>> On 08.08.17 at 17:59, wrote: > --- a/xen/arch/x86/genapic/delivery.c > +++ b/xen/arch/x86/genapic/delivery.c > @@ -30,7 +30,8 @@ void __init clustered_apic_check_flat(void) > printk("Enabling APIC mode: Flat. Using %d I/O APICs\n", nr_ioapics); > } > >

Re: [Xen-devel] [PATCH 1/3] x86/mm: Replace opencoded forms of l?e_{get, from}_page()

On 08/24/2017 02:14 PM, Andrew Cooper wrote: > No functional change (confirmed by diffing the disassembly). > > Signed-off-by: Andrew Cooper Reviewed-by: George Dunlap ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH RESEND v9] VT-d: use correct BDF for VF to search VT-d unit

On Fri, Aug 25, 2017 at 03:39:38AM -0600, Jan Beulich wrote: On 25.08.17 at 07:27, wrote: >> When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function' are >> under >> the scope of the same VT-d unit as the 'Physical Function'. A 'Physical >> Function' can be a

Re: [Xen-devel] [PATCH v3 3/3] tools/libxc: use superpages during restore of HVM guest

On Fri, Aug 25, Olaf Hering wrote: > I think with the new check of max_pages an overallocation can not happen > anymore. If at some point the domU still has room for a superpage, it > will be allocated. In case the batch does not fully fill the superpage, > the holes will be freed. In the next

[Xen-devel] [xen-unstable-smoke test] 112873: tolerable trouble: broken/pass - PUSHED

flight 112873 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/112873/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-pvops 2

Re: [Xen-devel] [PATCH v3 0/3] Rework vlapic timer to behave more like real-hardware

>>> On 08.08.17 at 15:32, wrote: > Anthony PERARD (3): > x86/vlapic: Introduce vlapic_update_timer > x86/vlapic: Keep timer running when switching between one-shot and > periodic mode > x86/vlapic: Apply change to TDCR right away to the timer > >

Re: [Xen-devel] [PATCH v2] x86/EFI: warn about r/o sections requiring relocations

On 25/08/17 15:34, Jan Beulich wrote: > EFI implementations may write-protect r/o sections, but we need to > apply relocations. Eliminate the one present case of a r/o section > with relocations (.init.text, which is now being combined with > .init.data into just .init). > > Also correct a few

[Xen-devel] [PATCH v2] x86/EFI: warn about r/o sections requiring relocations

EFI implementations may write-protect r/o sections, but we need to apply relocations. Eliminate the one present case of a r/o section with relocations (.init.text, which is now being combined with .init.data into just .init). Also correct a few other format strings (to account for the possibly

Re: [Xen-devel] [RFC PATCH 0/5] Extend resources to support more vcpus in single VM

Hi Tianyu, On Thu, Aug 24, 2017 at 10:52 PM, Lan Tianyu wrote: > > This patchset is to extend some resources(i.e, event channel, > hap and so) to support more vcpus for single VM. > > > Chao Gao (1): > xl/libacpi: extend lapic_id() to uint32_t > > Lan Tianyu (4): >

Re: [Xen-devel] [PATCH v3 3/3] tools/libxc: use superpages during restore of HVM guest

On Fri, Aug 25, Wei Liu wrote: > Maybe a middle ground is to scan the batch to see if pfns can be fit > into a whole super page? I don't think you can get a batch as big as 1G > but there should be a lot of 2M batches? I think with the new check of max_pages an overallocation can not happen

Re: [Xen-devel] [PATCH v2 1/4] x86/dom0: prevent access to MMCFG areas for PVH Dom0

On Fri, Aug 25, 2017 at 06:25:36AM -0600, Jan Beulich wrote: > >>> On 25.08.17 at 14:15, wrote: > > On Wed, Aug 23, 2017 at 02:16:38AM -0600, Jan Beulich wrote: > >> >>> On 22.08.17 at 15:54, wrote: > >> > On Tue, Aug 22, 2017 at 06:26:23AM -0600, Jan

Re: [Xen-devel] [PATCH v6] x86/hvm: Allow guest_request vm_events coming from userspace

>>> On 25.08.17 at 15:00, wrote: > On Vi, 2017-08-25 at 06:13 -0600, Jan Beulich wrote: >> > >> > > >> > > > >> > > > On 17.08.17 at 13:50, wrote: >> > --- a/xen/common/monitor.c >> > +++ b/xen/common/monitor.c >> > @@ -75,6 +75,7 @@ int

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

>>> On 25.08.17 at 05:15, wrote: > flight 112855 xen-unstable real [real] > http://logs.test-lab.xenproject.org/osstest/logs/112855/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >

Re: [Xen-devel] [PATCH v3 3/3] tools/libxc: use superpages during restore of HVM guest

On Fri, Aug 25, 2017 at 02:51:01PM +0200, Olaf Hering wrote: > On Fri, Aug 25, Wei Liu wrote: > > > I'm still unconvinced this works all the time because it still needs the > > assumption that the stream contains contiguous pfns. > > This is how it is done today. If the pfns start to arrive in

Re: [Xen-devel] Building XenGT for Intel embedded board

+GVT-g mailloop Hi Barooah, Thanks for your interests in XenGT. The document and git you mentioned is an old version to bring up XenGT on Intel Apollo Lake (code name) embedded board. It's using old architecture XenGT. After GVT-g has been upstreamed to kernel 4.10, we would like users to switch

Re: [Xen-devel] [PATCH v6] x86/hvm: Allow guest_request vm_events coming from userspace

On Vi, 2017-08-25 at 06:13 -0600, Jan Beulich wrote: > > > > > > > > > > > > > On 17.08.17 at 13:50, wrote: > > --- a/xen/common/monitor.c > > +++ b/xen/common/monitor.c > > @@ -75,6 +75,7 @@ int monitor_domctl(struct domain *d, struct > > xen_domctl_monitor_op *mop) > >

Re: [Xen-devel] Graphical virtualization in intel® Atom is possible?

+gvtg mailloop. We haven't tried Atom boards to support GVT-g. What we have verified are Intel Core platform (client machine), Intel Xeon E3 server with embedded GPU, and we also tried Apollo Lake (Code name) SoC board but Atom MinnowBoard can't support. Best regards. Hongbo Tel: +86-21-6116

Re: [Xen-devel] [PATCH v3 3/3] tools/libxc: use superpages during restore of HVM guest

On Fri, Aug 25, Wei Liu wrote: > I'm still unconvinced this works all the time because it still needs the > assumption that the stream contains contiguous pfns. This is how it is done today. If the pfns start to arrive in another order the format has to be changed to send a memory layout in

Re: [Xen-devel] [PATCH] common/gnttab: Introduce command line feature controls

On 25/08/17 14:29, Jan Beulich wrote: On 25.08.17 at 14:05, wrote: >> On 25/08/17 10:49, Jan Beulich wrote: >> On 24.08.17 at 16:50, wrote: --- a/docs/misc/xen-command-line.markdown +++ b/docs/misc/xen-command-line.markdown

Re: [Xen-devel] [PATCH] common/gnttab: Introduce command line feature controls

>>> On 25.08.17 at 14:10, wrote: > On 25/08/17 10:57, Jan Beulich wrote: > On 24.08.17 at 17:16, wrote: >>> On 24/08/17 16:01, Juergen Gross wrote: On 24/08/17 16:50, Andrew Cooper wrote: > ---

Re: [Xen-devel] [PATCH] common/gnttab: Introduce command line feature controls

>>> On 25.08.17 at 14:05, wrote: > On 25/08/17 10:49, Jan Beulich wrote: > On 24.08.17 at 16:50, wrote: >>> --- a/docs/misc/xen-command-line.markdown >>> +++ b/docs/misc/xen-command-line.markdown >>> @@ -868,6 +868,19 @@ Controls EPT

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

flight 112862 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/112862/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 112820 Tests

Re: [Xen-devel] [PATCH v2 1/4] x86/dom0: prevent access to MMCFG areas for PVH Dom0

>>> On 25.08.17 at 14:15, wrote: > On Wed, Aug 23, 2017 at 02:16:38AM -0600, Jan Beulich wrote: >> >>> On 22.08.17 at 15:54, wrote: >> > On Tue, Aug 22, 2017 at 06:26:23AM -0600, Jan Beulich wrote: >> >> >>> On 11.08.17 at 18:43,

Re: [Xen-devel] [PATCH 5/5] xen: add new hypercall to get grant table limits

>>> On 25.08.17 at 14:03, wrote: > On 25/08/17 13:58, Jan Beulich wrote: > On 25.08.17 at 13:40, wrote: >>> In the Linux kernel I would then: >>> >>> - Re-add grant v2 support >>> - Add boot parameter for selecting grant v1 or v2 >>> - Use grant v2 if

Re: [Xen-devel] [PATCH] common/gnttab: Introduce command line feature controls

On 25/08/17 14:10, Andrew Cooper wrote: > On 25/08/17 10:57, Jan Beulich wrote: > On 24.08.17 at 17:16, wrote: >>> On 24/08/17 16:01, Juergen Gross wrote: On 24/08/17 16:50, Andrew Cooper wrote: > --- a/docs/misc/xen-command-line.markdown > +++

Re: [Xen-devel] [PATCH v2 1/4] x86/dom0: prevent access to MMCFG areas for PVH Dom0

On Wed, Aug 23, 2017 at 02:16:38AM -0600, Jan Beulich wrote: > >>> On 22.08.17 at 15:54, wrote: > > On Tue, Aug 22, 2017 at 06:26:23AM -0600, Jan Beulich wrote: > >> >>> On 11.08.17 at 18:43, wrote: > >> > --- a/xen/arch/x86/dom0_build.c > >> > +++

Re: [Xen-devel] [PATCH v6] x86/hvm: Allow guest_request vm_events coming from userspace

>>> On 17.08.17 at 13:50, wrote: > --- a/xen/common/monitor.c > +++ b/xen/common/monitor.c > @@ -75,6 +75,7 @@ int monitor_domctl(struct domain *d, struct > xen_domctl_monitor_op *mop) > domain_pause(d); > d->monitor.guest_request_sync =

Re: [Xen-devel] [PATCH] common/gnttab: Introduce command line feature controls

On 25/08/17 10:57, Jan Beulich wrote: On 24.08.17 at 17:16, wrote: >> On 24/08/17 16:01, Juergen Gross wrote: >>> On 24/08/17 16:50, Andrew Cooper wrote: --- a/docs/misc/xen-command-line.markdown +++ b/docs/misc/xen-command-line.markdown @@ -868,6

  1   2   >