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

flight 117063 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/117063/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl broken build-amd64

Re: [Xen-devel] [v2 04/16] xen/arm: Extend copy_to_guest to support zeroing guest VA and use it

On Tue, 12 Dec 2017, Julien Grall wrote: > The function copy_to_guest can easily be extended to support zeroing > guest VA. To avoid using a new bit, it is considered that a NULL buffer > (i.e buf == NULL) means the guest memory will be zeroed. > > Lastly, reimplement raw_clear_guest using

Re: [Xen-devel] [v2 07/16] xen/arm: Introduce copy_to_guest_phys_flush_dcache

On Tue, 12 Dec 2017, Julien Grall wrote: > This new function will be used in a follow-up patch to copy data to the guest > using the IPA (aka guest physical address) and then clean the cache. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini

[Xen-devel] backtrace in drivers/net/xen-netback

I have the following traceback from xen-netback, under kernel 4.9.58. Does anyone know what might be going on here? [ cut here ] kernel BUG at drivers/net/xen-netback/rx.c:325! invalid opcode: [#1] SMP task: 88028f18cec0 task.stack: c90045e08000 RIP: e030:[]

[Xen-devel] [RFC PATCH v3 1/2] xen/pvh: Add memory map pointer to hvm_start_info struct

The start info structure that is defined as part of the x86/HVM direct boot ABI and used for starting Xen PVH guests would be more versatile if it also included a way to pass information about the memory map to the guest. This would allow KVM guests to share the same entry point. ---

[Xen-devel] [RFC PATCH v3 2/2] KVM: x86: Allow Qemu/KVM to use PVH entry point

For certain applications it is desirable to rapidly boot a KVM virtual machine. In cases where legacy hardware and software support within the guest is not needed, Qemu should be able to boot directly into the uncompressed Linux kernel binary without the need to run firmware. There already exists

Re: [Xen-devel] [PATCH V1 1/1] Xen/libxl: Perform PCI reset using 'reset' SysFS attribute

Any comments on this patch?. Thanks. On 12/7/2017 4:26 PM, Govinda Tatti wrote: The life-cycle of a PCI device in Xen pciback is complex and is constrained by the generic PCI locking mechanism. - It starts with the device being bound to us, for which we do a function reset (done via SysFS

Re: [Xen-devel] [PATCH 5/6] x86/mm: clean up SHARED_M2P{, _ENTRY} uses

On 12/12/2017 03:08 PM, Jan Beulich wrote: > Stop open-coding SHARED_M2P() and drop a pointless use of it from > paging_mfn_is_dirty() (!VALID_M2P() is a superset of SHARED_M2P()) and > another one from free_page_type() (prior assertions render this > redundant). > > Signed-off-by: Jan Beulich

[Xen-devel] [v2 16/16] xen/arm: traps: Merge do_trap_instr_abort_guest and do_trap_data_abort_guest

The two helpers do_trap_instr_abort_guest and do_trap_data_abort_guest are used trap stage-2 abort. While the former is only handling prefetch abort and the latter data abort, they are very similarly and does not warrant to have separate helpers. For instance, merging the both will make easier to

[Xen-devel] [v2 04/16] xen/arm: Extend copy_to_guest to support zeroing guest VA and use it

The function copy_to_guest can easily be extended to support zeroing guest VA. To avoid using a new bit, it is considered that a NULL buffer (i.e buf == NULL) means the guest memory will be zeroed. Lastly, reimplement raw_clear_guest using copy_to_guest. Signed-off-by: Julien Grall

[Xen-devel] [v2 15/16] xen/arm: traps: Move the definition of mmio_info_t in try_handle_mmio

mmio_info_t is currently filled by do_trap_data_guest_abort but only important when emulation an MMIO region. A follow-up patch will merge stage-2 prefetch abort and stage-2 data abort in a single helper. To prepare that, mmio_info_t is now filled by try_handle_mmio. Signed-off-by: Julien Grall

[Xen-devel] [v2 09/16] xen/arm: domain_build: Rework initrd_load to use the generic copy helper

The function initrd_load is dealing with IPA but uses gvirt_to_maddr to do the translation. This is currently working fine because the stage-1 MMU is disabled. Furthermore, the function is implementing its own copy to guest resulting in code duplication and making more difficult to update the

[Xen-devel] [v2 02/16] xen/arm: raw_copy_to_guest_helper: Rework the prototype and rename it

All the helpers within arch/arm/guestcopy.c are doing the same things: copy data from/to the guest. At the moment, the logic is duplicated in each helpers making more difficult to implement new variant. The first step for the consolidation is to get a common prototype and a base. For convenience

[Xen-devel] [v2 14/16] xen/arm: traps: Remove the field gva from mmio_info_t

mmio_info_t is used to gather information in order do emulation of a region. Guest virtual address is unlikely to be a useful information and not currently used. So remove the field gva from mmio_info_t and replace by a local variable. Signed-off-by: Julien Grall

[Xen-devel] [v2 00/16] xen/arm: Stage-2 handling cleanup

Hi all, This patch series is a collection of cleanup around stage-2 handling. They are consolidating different pieces of the hypervisor. This will make easier to maintain and update stage-2 change in the future. For all the changes see in each patch. Cheers, Julien Grall (16): xen/arm:

[Xen-devel] [v2 07/16] xen/arm: Introduce copy_to_guest_phys_flush_dcache

This new function will be used in a follow-up patch to copy data to the guest using the IPA (aka guest physical address) and then clean the cache. Signed-off-by: Julien Grall --- Changes in v2: - Use the new interface --- xen/arch/arm/guestcopy.c

[Xen-devel] [v2 13/16] xen/arm: p2m: Fold p2m_tlb_flush into p2m_force_tlb_flush_sync

p2m_tlb_flush is called in 2 places: p2m_alloc_table and p2m_force_tlb_flush_sync. p2m_alloc_table is called when the domain is initialized and could be replace by a call to p2m_force_tlb_flush_sync with the P2M write locked. This seems a bit pointless but would allow to have a single API for

[Xen-devel] [v2 11/16] xen/arm: p2m: Rename p2m_flush_tlb and p2m_flush_tlb_sync

Rename p2m_flush_tlb and p2m_flush_tlb_sync to respectively p2m_tlb_flush and p2m_force_tlb_flush_sync. At first glance, inverting 'flush' and 'tlb' might seem pointless but would be helpful in the future in order to get more easily some code ported from x86 P2M or even to shared with. For

[Xen-devel] [v2 01/16] xen/arm: raw_copy_to_guest_helper: Rename flush_dcache to flags

In a follow-up patch, it will be necessary to pass more flags to the function. Rename flush_dcache to flags and introduce a define to tell whether the cache needs to be flushed after the copy. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini

Re: [Xen-devel] [PATCH] x86/PCI: limit the size of the 64bit BAR to 256GB

On 12/12/2017 01:38 PM, Christian König wrote: > Am 12.12.2017 um 19:12 schrieb Bjorn Helgaas: >> [+cc Boris, Juergen, xen-devel] >> >> On Mon, Dec 11, 2017 at 04:04:52PM +0100, Christian König wrote: >>> Xen hides a bit of system memory from the OS for its own purpose by >>> intercepting e820.

[Xen-devel] [adhoc test] 117093: trouble: broken/pass

[adhoc adhoc] harness 67f2142: production-config[-cambridge]: update TftpDiVersion_j... 117093: trouble: broken/pass flight 117093 xen-unstable adhoc [adhoc] http://logs.test-lab.xenproject.org/osstest/logs/117093/ Failures and problems with tests :-( Tests which did not succeed and are

Re: [Xen-devel] [PATCH 4/6] x86/shadow: widen reference count

On 12/12/2017 03:07 PM, Jan Beulich wrote: > Utilize as many of the bits available in the union as possible, without > (just to be on the safe side) colliding with any of the bits outside of > PGT_type_mask. > > Signed-off-by: Jan Beulich > > ---

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

flight 117084 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/117084/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken

[Xen-devel] [adhoc test] 117105: tolerable ALL FAIL

[adhoc adhoc] harness 67f2142: production-config[-cambridge]: update TftpDiVersion_j... 117105: tolerable ALL FAIL flight 117105 xen-unstable adhoc [adhoc] http://logs.test-lab.xenproject.org/osstest/logs/117105/ Failures :-/ but no regressions. Tests which did not succeed, but are not

Re: [Xen-devel] [PATCH] xen: XEN_ACPI_PROCESSOR is Dom0-only

On 12/12/2017 05:18 AM, Jan Beulich wrote: > Add a respective dependency. > > Signed-off-by: Jan Beulich Committed to for-linus-4.15. -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

Re: [Xen-devel] [v2 02/16] xen/arm: raw_copy_to_guest_helper: Rework the prototype and rename it

On Tue, 12 Dec 2017, Julien Grall wrote: > All the helpers within arch/arm/guestcopy.c are doing the same things: > copy data from/to the guest. > > At the moment, the logic is duplicated in each helpers making more > difficult to implement new variant. > > The first step for the consolidation

Re: [Xen-devel] [v2 16/16] xen/arm: traps: Merge do_trap_instr_abort_guest and do_trap_data_abort_guest

On Tue, 12 Dec 2017, Julien Grall wrote: > The two helpers do_trap_instr_abort_guest and do_trap_data_abort_guest > are used trap stage-2 abort. While the former is only handling prefetch > abort and the latter data abort, they are very similarly and does not > warrant to have separate helpers. >

[Xen-devel] [xen-4.5-testing test] 117101: trouble: blocked/broken

flight 117101 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/117101/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-prev

Re: [Xen-devel] [PATCH] x86/PCI: limit the size of the 64bit BAR to 256GB

Am 12.12.2017 um 19:12 schrieb Bjorn Helgaas: [+cc Boris, Juergen, xen-devel] On Mon, Dec 11, 2017 at 04:04:52PM +0100, Christian König wrote: Xen hides a bit of system memory from the OS for its own purpose by intercepting e820. This memory is unfortunately not reported as reserved, but

Re: [Xen-devel] [v2 03/16] xen/arm: Extend copy_to_guest to support copying from guest VA and use it

On Tue, 12 Dec 2017, Julien Grall wrote: > The only differences between copy_to_guest (formerly called > raw_copy_to_guest_helper) and raw_copy_from_guest is: > - The direction of the memcpy > - The permission use for translating the address > > Extend copy_to_guest to support copying

Re: [Xen-devel] [v2 06/16] xen/arm: Extend copy_to_guest to support copying from/to guest physical address

On Tue, 12 Dec 2017, Julien Grall wrote: > The only differences between copy_to_guest and access_guest_memory_by_ipa are: > - The latter does not support copying data crossing page boundary > - The former is copying from/to guest VA whilst the latter from > guest PA > > copy_to_guest

Re: [Xen-devel] [RFC Patch v4 2/8] ioreq: bump the number of IOREQ page to 4 pages

On Tue, Dec 12, 2017 at 09:07:46AM +, Paul Durrant wrote: >> -Original Message- >[snip] >> >> Hi, Paul. >> >> I merged the two qemu patches, the privcmd patch [1] and did some tests. >> I encountered a small issue and report it to you, so you can pay more >> attention to it when

[Xen-devel] [PATCH v9] x86/altp2m: support for setting restrictions for an array of pages

From: Razvan Cojocaru For the default EPT view we have xc_set_mem_access_multi(), which is able to set an array of pages to an array of access rights with a single hypercall. However, this functionality was lacking for the altp2m subsystem, which could only set page

Re: [Xen-devel] [PATCH] xen: XEN_ACPI_PROCESSOR is Dom0-only

On 12/12/17 11:18, Jan Beulich wrote: > Add a respective dependency. > > Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

[Xen-devel] [linux-4.1 test] 117075: trouble: blocked/broken/fail/pass

flight 117075 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/117075/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl broken

[Xen-devel] Xen Security Advisory 249 - broken x86 shadow mode refcount overflow check

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-249 version 2 broken x86 shadow mode refcount overflow check UPDATES IN VERSION 2 Public release. Provide metadata file. ISSUE

[Xen-devel] Xen Security Advisory 251 - improper bug check in x86 log-dirty handling

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-251 version 2 improper bug check in x86 log-dirty handling UPDATES IN VERSION 2 Public release. Provide information for Xen

[Xen-devel] Xen Security Advisory 250 - improper x86 shadow mode refcount error handling

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-250 version 2 improper x86 shadow mode refcount error handling UPDATES IN VERSION 2 Public release. Provide metadata file. ISSUE

[Xen-devel] Xen Security Advisory 248 - x86 PV guests may gain access to internally used pages

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-248 version 2 x86 PV guests may gain access to internally used pages UPDATES IN VERSION 2 Public release. Provide metadata file. ISSUE

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

flight 117079 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/117079/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-i386

Re: [Xen-devel] [PATCH v14 07/11] x86/mm: add an extra command to HYPERVISOR_mmu_update...

On 12/12/17 13:25, Jan Beulich wrote: On 28.11.17 at 16:08, wrote: >> @@ -1905,7 +1906,8 @@ static int mod_l1_entry(l1_pgentry_t *pl1e, >> l1_pgentry_t nl1e, >> } >> >> /* Translate foreign guest address. */ >> -if (

[Xen-devel] [PATCH v6 4/4] hw: convert XenInput keyboard to keycodemapdb

Replace the scancode2linux table with an automatically generated table. In doing so, the XenFB keyboard handler is also converted to the modern InputEvent framework. Signed-off-by: Daniel P. Berrange --- hw/display/xenfb.c | 138

[Xen-devel] [PATCH v6 2/4] hw: convert ps2 device to keycodemapdb

Replace the qcode_to_keycode_set1, qcode_to_keycode_set2, and qcode_to_keycode_set3 tables with automatically generated tables. Missing entries in qcode_to_keycode_set1 now fixed: - Q_KEY_CODE_SYSRQ -> 0x54 - Q_KEY_CODE_PRINT -> 0x54 (NB ignored due to special case) - Q_KEY_CODE_AGAIN ->

[Xen-devel] [PATCH v6 1/4] hw: convert virtio-input-hid device to keycodemapdb

Replace the keymap_qcode table with automatically generated tables. Missing entries in keymap_qcode now fixed: Q_KEY_CODE_ASTERISK -> KEY_KPASTERISK Q_KEY_CODE_KP_MULTIPLY -> KEY_KPASTERISK Q_KEY_CODE_STOP -> KEY_STOP Q_KEY_CODE_AGAIN -> KEY_AGAIN Q_KEY_CODE_PROPS -> KEY_PROPS

[Xen-devel] [PATCH v6 3/4] hw: convert the escc device to keycodemapdb

Replace the qcode_to_keycode table with automatically generated tables. Missing entries in qcode_to_keycode now fixed: - Q_KEY_CODE_KP_COMMA -> 0x2d Signed-off-by: Daniel P. Berrange --- Makefile | 1 + hw/char/escc.c | 126

[Xen-devel] [PATCH v6 0/4] Convert hw backends to use keycodemapdb

This is a followup to v1: https://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg02047.html v2: https://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg02471.html v3: https://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg02517.html v4:

Re: [Xen-devel] [PATCH 1/2] x86/E820: don't overrun array

>>> On 12.12.17 at 12:18, wrote: > On 12/12/17 11:10, Jan Beulich wrote: >> The bounds check needs to be done after the increment, not before, or >> else it needs to use a one lower immediate. Also use word operations >> rather than byte ones for both the increment and

Re: [Xen-devel] [PATCH 2/2] x86/E820: improve insn selection

>>> On 12.12.17 at 12:21, wrote: > On 12/12/17 11:10, Jan Beulich wrote: >> ..., largely to shrink code size a little: >> - use TEST instead of CMP with zero immediate >> - use MOVZWL instead of AND with 0x immediate >> - compute final highmem_bk value in registers,

Re: [Xen-devel] [RFC v3 4/4] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

Hi Sameer, On 12/05/2017 09:29 AM, Sameer Goel wrote: +static +struct arm_smmu_device *arm_smmu_get_by_fwnode(struct fwnode_handle *fwnode) +{ + struct arm_smmu_device *smmu = NULL; + + spin_lock(_smmu_devices_lock); + list_for_each_entry(smmu, _smmu_devices, devices) { +

Re: [Xen-devel] [RFC Patch v4 2/8] ioreq: bump the number of IOREQ page to 4 pages

> -Original Message- [snip] > > Hi, Paul. > > I merged the two qemu patches, the privcmd patch [1] and did some tests. > I encountered a small issue and report it to you, so you can pay more > attention to it when doing some tests. The symptom is that using the new > interface to map

Re: [Xen-devel] [PATCH v2 3/3] x86/setup: remap Xen image up to PFN_DOWN(__pa(_end))

>>> On 11.12.17 at 16:12, wrote: > On Thu, Dec 07, 2017 at 05:02:02AM -0700, Jan Beulich wrote: >> >>> On 04.12.17 at 11:24, wrote: >> > Current limit, PFN_DOWN(xen_phys_start), introduced by commit b280442 >> > (x86: make Xen early boot code

Re: [Xen-devel] [RFC Patch v4 2/8] ioreq: bump the number of IOREQ page to 4 pages

On Fri, Dec 08, 2017 at 11:06:43AM +, Paul Durrant wrote: >> -Original Message- >> From: Chao Gao [mailto:chao@intel.com] >> Sent: 07 December 2017 06:57 >> To: Paul Durrant >> Cc: Stefano Stabellini ; Wei Liu >>

Re: [Xen-devel] [RFC PATCH v2 1/2] xen/pvh: Add memory map pointer to hvm_start_info struct

>>> On 11.12.17 at 22:59, wrote: > On 08/12/2017 09:49, Jan Beulich wrote: >>> + * The layout of each entry in the memory map table is as follows and no >>> + * padding is used between entries in the array: >>> + * >>> + * 0 ++ >>> + *| addr |

Re: [Xen-devel] [RFC PATCH v2 1/2] xen/pvh: Add memory map pointer to hvm_start_info struct

On 12/12/2017 09:06, Jan Beulich wrote: On 11.12.17 at 22:59, wrote: >> On 08/12/2017 09:49, Jan Beulich wrote: + * The layout of each entry in the memory map table is as follows and no + * padding is used between entries in the array: + * + * 0

Re: [Xen-devel] [PATCH v2 2/3] x86/setup: do not relocate Xen over current Xen image placement

>>> On 11.12.17 at 15:59, wrote: > On Thu, Dec 07, 2017 at 04:51:32AM -0700, Jan Beulich wrote: >> >>> On 04.12.17 at 11:24, wrote: >> > +if ( (end > s) && (end - reloc_size >= _end - _start) ) >> >> In your earlier mails following v1 you

Re: [Xen-devel] [PATCH v14 07/11] x86/mm: add an extra command to HYPERVISOR_mmu_update...

>>> On 12.12.17 at 14:52, wrote: > On 12/12/17 13:25, Jan Beulich wrote: > On 28.11.17 at 16:08, wrote: >>> @@ -1905,7 +1906,8 @@ static int mod_l1_entry(l1_pgentry_t *pl1e, > l1_pgentry_t nl1e, >>> } >>> >>> /*

[Xen-devel] [linux-4.9 test] 117076: trouble: blocked/broken/pass

flight 117076 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/117076/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-amd64

Re: [Xen-devel] [PATCH v14 07/11] x86/mm: add an extra command to HYPERVISOR_mmu_update...

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 12 December 2017 13:25 > To: Paul Durrant > Cc: Andrew Cooper ; Wei Liu > ; George Dunlap ; Ian > Jackson

Re: [Xen-devel] [PATCH V3 2/2] Xen/PCIback: Implement PCI flr/slot/bus reset with 'reset' SysFS attribute

>>> On 12.12.17 at 15:48, wrote: > Thanks Jan for your review comments. Please see below for my comments. First of all - can you please do something about your reply style? HTML mail should be avoided. You'll see that the (plain text) reply as a result is rather hard to

Re: [Xen-devel] [PATCH V3 2/2] Xen/PCIback: Implement PCI flr/slot/bus reset with 'reset' SysFS attribute

Thanks Jan for your review comments. Please see below for my comments. On 12/8/2017 3:34 AM, Jan Beulich wrote: On 07.12.17 at 23:21, wrote: Due to the

[Xen-devel] [PATCH 1/6] x86/shadow: drop further 32-bit relics

PV guests don't ever get shadowed in other than 4-level mode anymore; commit 5a3ce8f85e ("x86/shadow: drop stray name tags from sh_{guest_get,map}_eff_l1e()") didn't go quite fare enough (and there's a good chance that further cleanup opportunity exists, which I simply didn't notice).

[Xen-devel] [PATCH 2/6] x86/shadow: remove pointless loops over all vCPU-s

The vCPU count can be had more directly. Signed-off-by: Jan Beulich --- In the sh_make_shadow() case the question is whether it really was intended to count all vCPU-s, rather than e.g. only all initialized ones. I guess the problem would be the phase before the guest actually

[Xen-devel] [PATCH 3/6] x86/shadow: ignore sh_pin() failure in one more case

Following what we've already done in the XSA-250 fix, convert another sh_pin() caller to no longer fail the higher level operation if pinning fails, as pinning is a performance optimization only in those places. Suggested-by: Tim Deegan Signed-off-by: Jan Beulich

[Xen-devel] [PATCH 4/6] x86/shadow: widen reference count

Utilize as many of the bits available in the union as possible, without (just to be on the safe side) colliding with any of the bits outside of PGT_type_mask. Signed-off-by: Jan Beulich --- a/xen/arch/x86/mm/shadow/private.h +++ b/xen/arch/x86/mm/shadow/private.h @@ -510,7

Re: [Xen-devel] [PATCH V3 1/2] Drivers/PCI: Export pcie_has_flr() interface

On Fri, Dec 08, 2017 at 02:24:24PM -0600, Bjorn Helgaas wrote: > I'd rather change pcie_flr() so you could *always* call it, and it > would return 0, -ENOTTY, or whatever, based on whether FLR is > supported. Is that feasible? > > I don't like the "Can I do this? Ok, do this" style of

[Xen-devel] [PATCH 5/6] x86/mm: clean up SHARED_M2P{,_ENTRY} uses

Stop open-coding SHARED_M2P() and drop a pointless use of it from paging_mfn_is_dirty() (!VALID_M2P() is a superset of SHARED_M2P()) and another one from free_page_type() (prior assertions render this redundant). Signed-off-by: Jan Beulich --- a/xen/arch/x86/mm.c +++

[Xen-devel] [PATCH 6/6] x86: use paging_mark_pfn_dirty()

... in preference over paging_mark_dirty(), when the PFN is known anyway. Signed-off-by: Jan Beulich --- This has a contextual dependency on https://lists.xenproject.org/archives/html/xen-devel/2017-12/msg00151.html which is ready to go in, just waiting for the tree to fully

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

flight 117085 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/117085/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-prev

Re: [Xen-devel] [PATCH V3 2/2] Xen/PCIback: Implement PCI flr/slot/bus reset with 'reset' SysFS attribute

On 12/12/2017 9:01 AM, Jan Beulich wrote: On 12.12.17 at 15:48, wrote: Thanks Jan for your review comments. Please see below for my comments. First of all - can you please do something about your reply style? HTML mail should be avoided. You'll see that the (plain

Re: [Xen-devel] Windows PV drivers and Windows 10 / Windows Server 2016

Moving xen-devel to bcc and addressing win-pv-devel list... > -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > Of Steven Haigh > Sent: 12 December 2017 11:33 > To: xen-de...@lists.xen.org > Subject: [Xen-devel] Windows PV drivers and Windows

Re: [Xen-devel] [RFC v3 4/4] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

On 12/12/2017 1:09 AM, Manish Jaggi wrote: > Hi Sameer, > > On 12/05/2017 09:29 AM, Sameer Goel wrote: > >> +static >> +struct arm_smmu_device *arm_smmu_get_by_fwnode(struct fwnode_handle *fwnode) >> +{ >> +    struct arm_smmu_device *smmu = NULL; >> + >> +    spin_lock(_smmu_devices_lock); >> + 

[Xen-devel] [PATCH 2/2] x86-64/Xen: eliminate W+X mappings

A few thousand such pages are usually left around due to the re-use of L1 tables having been provided by the hypervisor (Dom0) or tool stack (DomU). Set NX in the direct map variant, which needs to be done in L2 due to the dual use of the re-used L1s. For x86_configure_nx() to actually do what it

[Xen-devel] [PATCH 1/2] x86: consider effective protection attributes in W+X check

Using just the leaf page table entry flags would cause a false warning in case _PAGE_RW is clear or _PAGE_NX is set in a higher level entry. Hand through both the current entry's flags as well as the accumulated effective value (the latter as pgprotval_t instead of pgprot_t, as it's not an actual

Re: [Xen-devel] [PATCH 1/2] x86: consider effective protection attributes in W+X check

>>> On 12.12.17 at 11:36, wrote: > * Jan Beulich wrote: > >> Using just the leaf page table entry flags would cause a false warning >> in case _PAGE_RW is clear or _PAGE_NX is set in a higher level entry. > > Good find - I assume this bug can cause both

[Xen-devel] [PATCH 0/2] x86/E820: a fix and an improvement

1: don't overrun array 2: improve insn selection Signed-off-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 1/2] x86/E820: don't overrun array

On 12/12/17 11:10, Jan Beulich wrote: > The bounds check needs to be done after the increment, not before, or > else it needs to use a one lower immediate. Also use word operations > rather than byte ones for both the increment and the compare (allowing > E820_BIOS_MAX to be more easily bumped,

Re: [Xen-devel] [PATCH 2/2] x86/E820: improve insn selection

On 12/12/17 11:10, Jan Beulich wrote: > ..., largely to shrink code size a little: > - use TEST instead of CMP with zero immediate > - use MOVZWL instead of AND with 0x immediate > - compute final highmem_bk value in registers, accessing memory just > once > > Signed-off-by: Jan Beulich

Re: [Xen-devel] Xen Security Advisory 240 (CVE-2017-15595) - Unlimited recursion in linear pagetable de-typing

On Tue, Dec 12, 2017 at 10:03 AM, Steven Haigh wrote: > On Tuesday, 12 December 2017 5:16:06 AM AEDT Xen. org security team wrote: >> Xen Security Advisory CVE-2017-15595 / XSA-240 >>version 6 >> >>Unlimited recursion in

[Xen-devel] [PATCH 0/2] x86: deal with remaining W+X pages on Xen

The two patches here are entirely independent (i.e. they could by applied in any order and/or go through separate trees), but for the warning to go away both are necessary. 1: x86: consider effective protection attributes in W+X check 2: x86-64/Xen: eliminate W+X pages Signed-off-by: Jan Beulich

Re: [Xen-devel] [PATCH 2/2] x86-64/Xen: eliminate W+X mappings

* Jan Beulich wrote: > >>> On 12.12.17 at 11:38, wrote: > > * Jan Beulich wrote: > >> --- 4.15-rc3/arch/x86/xen/mmu_pv.c > >> +++ 4.15-rc3-x86_64-Xen-avoid-W+X/arch/x86/xen/mmu_pv.c > >> @@ -1902,6 +1902,16 @@ void __init

[Xen-devel] Windows PV drivers and Windows 10 / Windows Server 2016

Hi all, Re the Windows PV drivers - I've tried v8.2.0 on Windows 10, and it required me to put Windows into TEST MODE to still load the drivers. Bringing it out of test mode results in the Xen PV drivers being uninstalled. I now have to create a Windows Server 2016 DomU and I'm wondering if

[Xen-devel] [PATCH] xen: XEN_ACPI_PROCESSOR is Dom0-only

Add a respective dependency. Signed-off-by: Jan Beulich --- drivers/xen/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- 4.15-rc3/drivers/xen/Kconfig +++ 4.15-rc3-xen-ACPI_PROCESSOR-Dom0/drivers/xen/Kconfig @@ -269,7 +269,7 @@ config XEN_ACPI_HOTPLUG_CPU

Re: [Xen-devel] [PATCH 1/2] x86: consider effective protection attributes in W+X check

* Jan Beulich wrote: > Using just the leaf page table entry flags would cause a false warning > in case _PAGE_RW is clear or _PAGE_NX is set in a higher level entry. Good find - I assume this bug can cause both false positives and false negatives as well, right? Thanks,

Re: [Xen-devel] [PATCH 2/2] x86-64/Xen: eliminate W+X mappings

* Jan Beulich wrote: > A few thousand such pages are usually left around due to the re-use of > L1 tables having been provided by the hypervisor (Dom0) or tool stack > (DomU). Set NX in the direct map variant, which needs to be done in L2 > due to the dual use of the re-used

Re: [Xen-devel] [PATCH 2/2] x86-64/Xen: eliminate W+X mappings

>>> On 12.12.17 at 11:38, wrote: > * Jan Beulich wrote: >> --- 4.15-rc3/arch/x86/xen/mmu_pv.c >> +++ 4.15-rc3-x86_64-Xen-avoid-W+X/arch/x86/xen/mmu_pv.c >> @@ -1902,6 +1902,16 @@ void __init xen_setup_kernel_pagetable(p >> /* Graft it onto L4[511][510]

[Xen-devel] [distros-debian-snapshot test] 72678: trouble: blocked/broken

flight 72678 distros-debian-snapshot real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72678/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvopsbroken

[Xen-devel] [PATCH 2/2] x86/E820: improve insn selection

..., largely to shrink code size a little: - use TEST instead of CMP with zero immediate - use MOVZWL instead of AND with 0x immediate - compute final highmem_bk value in registers, accessing memory just once Signed-off-by: Jan Beulich --- a/xen/arch/x86/boot/mem.S +++

[Xen-devel] [PATCH 1/2] x86/E820: don't overrun array

The bounds check needs to be done after the increment, not before, or else it needs to use a one lower immediate. Also use word operations rather than byte ones for both the increment and the compare (allowing E820_BIOS_MAX to be more easily bumped, should the need ever arise). Signed-off-by: Jan

Re: [Xen-devel] [PATCH 2/2] x86-64/Xen: eliminate W+X mappings

On 12/12/17 11:48, Jan Beulich wrote: On 12.12.17 at 11:38, wrote: >> * Jan Beulich wrote: >>> --- 4.15-rc3/arch/x86/xen/mmu_pv.c >>> +++ 4.15-rc3-x86_64-Xen-avoid-W+X/arch/x86/xen/mmu_pv.c >>> @@ -1902,6 +1902,16 @@ void __init

[Xen-devel] [linux-linus test] 117080: trouble: blocked/broken/pass

flight 117080 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/117080/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl broken

[Xen-devel] [adhoc test] 117089: trouble: broken/preparing/queued

[adhoc adhoc] harness 67f2142: production-config[-cambridge]: update TftpDiVersion_j... 117089: trouble: broken/preparing/queued flight 117089 xen-unstable running [adhoc] http://logs.test-lab.xenproject.org/osstest/logs/117089/ Failures and problems with tests :-( Tests which did not succeed

Re: [Xen-devel] [PATCH v14 07/11] x86/mm: add an extra command to HYPERVISOR_mmu_update...

>>> On 28.11.17 at 16:08, wrote: > @@ -1905,7 +1906,8 @@ static int mod_l1_entry(l1_pgentry_t *pl1e, > l1_pgentry_t nl1e, > } > > /* Translate foreign guest address. */ > -if ( paging_mode_translate(pg_dom) ) > +if ( cmd !=

[Xen-devel] [seabios test] 117081: trouble: blocked/broken

flight 117081 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/117081/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm broken build-i386

Re: [Xen-devel] [PATCH v7 for-next 03/12] vpci: introduce basic handlers to trap accesses to the PCI config space

>>> On 18.10.17 at 13:40, wrote: > +static int vpci_portio_read(const struct hvm_io_handler *handler, > +uint64_t addr, uint32_t size, uint64_t *data) > +{ > +struct domain *d = current->domain; const? > +unsigned int reg; > +

Re: [Xen-devel] [PATCH v7 for-next 04/12] x86/mmcfg: add handlers for the PVH Dom0 MMCFG areas

>>> On 18.10.17 at 13:40, wrote: > +int __hwdom_init register_vpci_mmcfg_handler(struct domain *d, paddr_t addr, > + unsigned int start_bus, > + unsigned int end_bus, > +