Re: [Xen-devel] [PATCH] x86/MCE, xen/mcelog: Make /dev/mcelog registration messages more precise

Borislav, How about skipping the misc_register() steps and keep silence if you know it is running as Dom0 ? as it is easy to know. Reviewed-by: Ethan Zhao On Wed, Jun 21, 2017 at 5:16 AM, Borislav Petkov wrote: > From: Juergen Gross

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

flight 110907 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/110907/ 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 test-amd64-amd64-libvirt 12

[Xen-devel] [PATCH] ARM: SMMUv2: Add compatible match entry for cavium smmuv2

This patch adds cavium,smmu-v2 compatible match entry in smmu driver Signed-off-by: Manish Jaggi --- xen/drivers/passthrough/arm/smmu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/arm/smmu.c index

[Xen-devel] [PATCH 3/4] ARM: ITS: Deny hardware domain access to its

This patch extends the gicv3_iomem_deny_access functionality by adding support for its region as well. Added function gicv3_its_deny_access. Signed-off-by: Manish Jaggi --- xen/arch/arm/gic-v3-its.c| 19 +++ xen/arch/arm/gic-v3.c| 7

[Xen-devel] [PATCH 4/4] ARM: ACPI: Add ITS to hardware domain MADT

This patch adds ITS information in hardware domain's MADT table. Also this patch interoduces .get_hwdom_madt_size in gic_hw_operations, to return the complete size of MADT table for hardware domain. Signed-off-by: Manish Jaggi --- xen/arch/arm/domain_build.c | 7 +--

[Xen-devel] [PATCH 0/4] ARM: ACPI: ITS: Add ITS Support for ACPI hardware domain

This patch series adds the support of ITS for ACPI hardware domain. It is tested on staging branch with has ITS v12 patchset by Andre. I have tried to incorporate the review comments on the RFC v1/v2 patch. The single patch in RFC is now split into 4 patches. Patch1: ARM: ITS: Add

[Xen-devel] [PATCH 2/4] ARM: ITS: ACPI: Introduce gicv3_its_acpi_init

This patch adds gicv3_its_acpi_init. To avoid duplicate code for initializing and adding to host_its_list a common function add_to_host_its_list is added which is called by both _dt_init and _acpi_init. Signed-off-by: Manish Jaggi --- xen/arch/arm/gic-v3-its.c| 49

[Xen-devel] [PATCH 1/4] ARM: ITS: Add translation_id to host_its

This patch adds a translation_id to host_its data structure. Value stored in this id should be copied over to hardware domains MADT table. Signed-off-by: Manish Jaggi --- xen/include/asm-arm/gic_v3_its.h | 2 ++ 1 file changed, 2 insertions(+) diff --git

[Xen-devel] [PATCH v2] docs: improve ARM passthrough doc

Add a warning: use passthrough with care. Add a pointer to the gic device tree bindings. Add an explanation on how to calculate irq numbers from device tree. Add a brief explanation of the reg property and a pointer to the xl docs for a description of the iomem property. Add a note that in the

Re: [Xen-devel] [PATCH] docs: improve ARM passthrough doc

On Tue, 20 Jun 2017, Julien Grall wrote: > Hi Stefano, > > On 06/16/2017 09:29 PM, Stefano Stabellini wrote: > > Add a warning: use passthrough with care. > > > > Add a pointer to the gic device tree bindings. Add an explanation on how > > to calculate irq numbers from device tree. > > > > Add

Re: [Xen-devel] [PATCH 2/3] xen-disk: add support for multi-page shared rings

On Tue, 20 Jun 2017, Paul Durrant wrote: > The blkif protocol has had provision for negotiation of multi-page shared > rings for some time now and many guest OS have support in their frontend > drivers. > > This patch makes the necessary modifications to xen-disk support a shared > ring up to

Re: [Xen-devel] [PATCH 1/3] xen-disk: only advertize feature-persistent if grant copy is not available

On Tue, 20 Jun 2017, Paul Durrant wrote: > If grant copy is available then it will always be used in preference to > persistent maps. In this case feature-persistent should not be advertized > to the frontend, otherwise it may needlessly copy data into persistently > granted buffers. > >

Re: [Xen-devel] [PATCH v2] xen: idle_loop: either deal with tasklets or go idle

On Tue, 20 Jun 2017, Dario Faggioli wrote: > In fact, there are two kinds of tasklets: vCPU and > softirq context. When we want to do vCPU context tasklet > work, we force the idle vCPU (of a particular pCPU) into > execution, and run it from there. > > This means there are two possible reasons

Re: [Xen-devel] [PATCH] xen/disk: don't leak stack data via response ring

On Tue, 20 Jun 2017, Jan Beulich wrote: > Rather than constructing a local structure instance on the stack, fill > the fields directly on the shared ring, just like other (Linux) > backends do. Build on the fact that all response structure flavors are > actually identical (the old code did make

[Xen-devel] [PATCH] x86/MCE, xen/mcelog: Make /dev/mcelog registration messages more precise

From: Juergen Gross When running under Xen as dom0, /dev/mcelog is being provided by Xen instead of the normal mcelog character device of the MCE core. Convert an error message being issued by the MCE core in this case to an informative message that Xen has registered the

Re: [Xen-devel] [PATCH v7 07/36] x86/mm: Don't use phys_to_virt in ioremap() if SME is active

On Fri, 16 Jun 2017, Tom Lendacky wrote: > Currently there is a check if the address being mapped is in the ISA > range (is_ISA_range()), and if it is then phys_to_virt() is used to > perform the mapping. When SME is active, however, this will result > in the mapping having the encryption bit

Re: [Xen-devel] [PATCH v4 9/9] arm/mem_access: Walk the guest's pt in software

Hi Tamas, [...] >> +if ( guest_walk_tables(v, gva, , ) < 0 ) >> +/* >> + * The software gva to ipa translation can still fail, e.g., if >> the >> + * gva is not mapped. >> + */ > > If you end up sending another round of the series, I

Re: [Xen-devel] [PATCH v7 06/36] x86/mm: Add Secure Memory Encryption (SME) support

On Fri, 16 Jun 2017, Tom Lendacky wrote: > > +config ARCH_HAS_MEM_ENCRYPT > + def_bool y > + depends on X86 That one is silly. The config switch is in the x86 KConfig file, so X86 is on. If you intended to move this to some generic place outside of x86/Kconfig then this should be

Re: [Xen-devel] [PATCH v4 9/9] arm/mem_access: Walk the guest's pt in software

On Tue, Jun 20, 2017 at 2:33 PM, Sergej Proskurin wrote: > In this commit, we make use of the gpt walk functionality introduced in > the previous commits. If mem_access is active, hardware-based gva to ipa > translation might fail, as gva_to_ipa uses the guest's

Re: [Xen-devel] [PATCH v7 19/36] x86/mm: Add support to access boot related data in the clear

On Fri, Jun 16, 2017 at 01:53:26PM -0500, Tom Lendacky wrote: > Boot data (such as EFI related data) is not encrypted when the system is > booted because UEFI/BIOS does not run with SME active. In order to access > this data properly it needs to be mapped decrypted. > > Update early_memremap() to

[Xen-devel] [PATCH v4 5/9] arm/mem_access: Extend BIT-operations to unsigned long long

We extend the BIT macro to using values of unsigned long long as to enable setting bits of 64-bit registers on AArch32. In addition, this commit adds a define holding the register width of 64 bit double-word registers. This define simplifies using the associated constants in the following

[Xen-devel] [PATCH v4 9/9] arm/mem_access: Walk the guest's pt in software

In this commit, we make use of the gpt walk functionality introduced in the previous commits. If mem_access is active, hardware-based gva to ipa translation might fail, as gva_to_ipa uses the guest's translation tables, access to which might be restricted by the active VTTBR. To side-step

[Xen-devel] [PATCH v4 7/9] arm/mem_access: Add long-descriptor based gpt

This commit adds functionality to walk the guest's page tables using the long-descriptor translation table format for both ARMv7 and ARMv8. Similar to the hardware architecture, the implementation supports different page granularities (4K, 16K, and 64K). The implementation is based on ARM DDI

[Xen-devel] [PATCH v4 2/9] arm/mem_access: Add defines supporting PTs with varying page sizes

The ARMv8 architecture supports pages with different (4K, 16K, and 64K) sizes. To enable guest page table walks for various configurations, this commit extends the defines and helpers of the current implementation. Signed-off-by: Sergej Proskurin --- Cc: Stefano

[Xen-devel] [PATCH v4 0/9] arm/mem_access: Walk guest page tables in SW if mem_access is active

Hi all, The function p2m_mem_access_check_and_get_page is called from the function get_page_from_gva if mem_access is active and the hardware-aided translation of the given guest virtual address (gva) into machine address fails. That is, if the stage-2 translation tables constrain access to the

[Xen-devel] [PATCH v4 4/9] arm/mem_access: Introduce GV2M_EXEC permission

We extend the current implementation by an additional permission, GV2M_EXEC, which will be used to describe execute permissions of PTE's as part of our guest translation table walk implementation. Signed-off-by: Sergej Proskurin Acked-by: Julien Grall

[Xen-devel] [PATCH v4 6/9] arm/mem_access: Add software guest-page-table walk

The function p2m_mem_access_check_and_get_page in mem_access.c translates a gva to an ipa by means of the hardware functionality of the ARM architecture. This is implemented in the function gva_to_ipa. If mem_access is active, hardware-based gva to ipa translation might fail, as gva_to_ipa uses

[Xen-devel] [PATCH v4 1/9] arm/mem_access: Add (TCR_|TTBCR_)* defines

This commit adds (TCR_|TTBCR_)* defines to simplify access to the respective register contents. At the same time, we adjust the macro TCR_T0SZ by using the newly introduced TCR_T0SZ_SHIFT instead of the hardcoded value. Signed-off-by: Sergej Proskurin --- Cc: Stefano

[Xen-devel] [PATCH v4 3/9] arm/mem_access: Add short-descriptor pte typedefs

The current implementation does not provide appropriate types for short-descriptor translation table entries. As such, this commit adds new types, which simplify managing the respective translation table entries. Signed-off-by: Sergej Proskurin --- Cc: Stefano Stabellini

[Xen-devel] [PATCH v4 8/9] arm/mem_access: Add short-descriptor based gpt

This commit adds functionality to walk the guest's page tables using the short-descriptor translation table format for both ARMv7 and ARMv8. The implementation is based on ARM DDI 0487B-a J1-6002 and ARM DDI 0406C-b B3-1506. Signed-off-by: Sergej Proskurin --- Cc:

[Xen-devel] [PATCH 2/2] x86/xen/efi: Init only efi struct members used by Xen

Current approach, wholesale efi struct initialization from efi_xen, is not good. Usually if new member is defined then it is properly initialized in drivers/firmware/efi/efi.c but not in arch/x86/xen/efi.c. As I saw it happened a few times until now. So, let's initialize only efi struct members

[Xen-devel] [PATCH 1/2] efi: Process MEMATTR table only if EFI_MEMMAP

Otherwise e.g. Xen dom0 on x86_64 EFI platforms crashes. In theory we can check EFI_PARAVIRT too, however, EFI_MEMMAP looks more generic and covers more cases. Signed-off-by: Daniel Kiper --- drivers/firmware/efi/efi.c |3 ++- 1 file changed, 2 insertions(+), 1

[Xen-devel] [PATCH 0/2] xen/efi: Fixes

Hey, Two small fixes for Xen dom0 running on x86_64 EFI platforms. I am CC-ing stable maintainers because similar stuff is needed for various stable kernels too. Unfortunately, almost every version needs a bit different set of fixes. So, please treat this email more as head up than real set of

Re: [Xen-devel] Fwd: VM Live Migration with Local Storage

On 12/06/17 04:16, Bruno Alvisio wrote: > Hello, > > I think it would be beneficial to add local disk migration feature for > ‘blkback' backend since it is one of the mostly used backends. I would > like to start a discussion about the design of the machinery needed to > achieve this feature. >

Re: [Xen-devel] Fwd: VM Live Migration with Local Storage

On Sun, Jun 11, 2017 at 08:16:04PM -0700, Bruno Alvisio wrote: > Hello, > > I think it would be beneficial to add local disk migration feature for > ‘blkback' backend since it is one of the mostly used backends. I would like > to start a discussion about the design of the machinery needed to

Re: [Xen-devel] stub domain crash related to bind_interdomain

On 06/20/2017 01:24 AM, Jan Beulich wrote: On 20.06.17 at 01:39, wrote: >> I have gotten messages like this sporadically in the qemu-dm log for stub >> domains, both at domain start and domain reboot: >> >> evtchn_open() -> 7 >> ERROR: bind_interdomain failed with

[Xen-devel] [PATCH v2] libxc: add xc_domain_add_to_physmap_batch to wrap XENMEM_add_to_physmap_batch

This is a preparation for the proposal "allow setting up shared memory areas between VMs from xl config file". See: V2: https://lists.xen.org/archives/html/xen-devel/2017-06/msg02256.html V1: https://lists.xen.org/archives/html/xen-devel/2017-05/msg01288.html The plan is to use

Re: [Xen-devel] [RFC v2]Proposal to allow setting up shared memory areas between VMs from xl config file

Hi, Thank you for the new proposal. On 06/20/2017 06:18 PM, Zhongze Liu wrote: In the example above. A memory area ID1 will be shared between vm1 and vm2. This area will be taken from vm1 and mapped into vm2's stage-2 page table. The parameter "prot=RO" means that this memory area are offered

Re: [Xen-devel] [PATCH v4 15/18] xen/pvcalls: implement the ioworker functions

On 06/15/2017 03:09 PM, Stefano Stabellini wrote: > We have one ioworker per socket. Each ioworker goes through the list of > outstanding read/write requests. Once all requests have been dealt with, > it returns. > > We use one atomic counter per socket for "read" operations and one > for "write"

[Xen-devel] [RFC v2]Proposal to allow setting up shared memory areas between VMs from xl config file

1. Motivation and Description Virtual machines use grant table hypercalls to setup a share page for inter-VMs communications. These hypercalls are used by all PV protocols today. However, very

Re: [Xen-devel] [PATCH v4 13/18] xen/pvcalls: implement release command

> + > +static int pvcalls_back_release_passive(struct xenbus_device *dev, > + struct pvcalls_fedata *fedata, > + struct sockpass_mapping *mappass) > +{ > + if (mappass->sock->sk != NULL) { > +

Re: [Xen-devel] [PATCH v4 12/18] xen/pvcalls: implement poll command

> @@ -499,6 +521,55 @@ static int pvcalls_back_accept(struct xenbus_device *dev, > static int pvcalls_back_poll(struct xenbus_device *dev, >struct xen_pvcalls_request *req) > { > + struct pvcalls_fedata *fedata; > + struct sockpass_mapping *mappass; > +

Re: [Xen-devel] [PATCH v4 04/27] x86: move PV invalid op emulation code

On Tue, Jun 20, 2017 at 10:21:27AM -0600, Jan Beulich wrote: > >>> On 08.06.17 at 19:11, wrote: > > @@ -1053,8 +982,8 @@ void do_invalid_op(struct cpu_user_regs *regs) > > > > if ( likely(guest_mode(regs)) ) > > { > > -if ( !emulate_invalid_rdtscp(regs) &&

Re: [Xen-devel] Notes on stubdoms and latency on ARM

Hi Julien, On 20 June 2017 at 03:45, Julien Grall wrote: >> On 19 June 2017 at 10:54, Stefano Stabellini >> wrote: >> But given the conversation so far, it seems likely that that is mainly due to the fact that context switching on ARM has

Re: [Xen-devel] [PATCH v7 11/36] x86/mm: Add SME support for read_cr3_pa()

On 6/20/2017 11:17 AM, Andy Lutomirski wrote: On Fri, Jun 16, 2017 at 11:51 AM, Tom Lendacky wrote: The cr3 register entry can contain the SME encryption mask that indicates the PGD is encrypted. The encryption mask should not be used when creating a virtual address

Re: [Xen-devel] [PATCH v4 05/27] x86/traps: remove now unused inclusion of emulate.h

>>> On 08.06.17 at 19:11, wrote: > Signed-off-by: Wei Liu Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 04/27] x86: move PV invalid op emulation code

>>> On 08.06.17 at 19:11, wrote: > @@ -1053,8 +982,8 @@ void do_invalid_op(struct cpu_user_regs *regs) > > if ( likely(guest_mode(regs)) ) > { > -if ( !emulate_invalid_rdtscp(regs) && > - !emulate_forced_invalid_op(regs) ) > +if (

Re: [Xen-devel] [PATCH v1 1/3] livepatch: Add local and global symbol resolution.

>>> On 20.06.17 at 17:59, wrote: > Our mechanism when deploying livepatches is to replace the loaded > livepatch with another one. Which means we only have on livepatch > applied and during the upgrade process have to load another one. I think this is the main problematic

Re: [Xen-devel] [PATCH v7 11/36] x86/mm: Add SME support for read_cr3_pa()

On Fri, Jun 16, 2017 at 11:51 AM, Tom Lendacky wrote: > The cr3 register entry can contain the SME encryption mask that indicates > the PGD is encrypted. The encryption mask should not be used when > creating a virtual address from the cr3 register, so remove the SME >

Re: [Xen-devel] [PATCH v4 07/18] xen/pvcalls: implement socket command

On Thu, Jun 15, 2017 at 12:09:36PM -0700, Stefano Stabellini wrote: > Just reply with success to the other end for now. Delay the allocation > of the actual socket to bind and/or connect. > > Signed-off-by: Stefano Stabellini > CC: boris.ostrov...@oracle.com > CC:

Re: [Xen-devel] [PATCH 3/3] xen-disk: use an IOThread per instance

> -Original Message- > From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo > Bonzini > Sent: 20 June 2017 17:08 > To: Paul Durrant ; xen-de...@lists.xenproject.org; > qemu-de...@nongnu.org; qemu-bl...@nongnu.org > Cc: Anthony Perard

Re: [Xen-devel] [PATCH 3/3] xen-disk: use an IOThread per instance

On 20/06/2017 15:47, Paul Durrant wrote: > This patch allocates an IOThread object for each xen_disk instance and > sets the AIO context appropriately on connect. This allows processing > of I/O to proceed in parallel. > > The patch also adds tracepoints into xen_disk to make it possible to >

Re: [Xen-devel] [PATCH v4 03/27] x86: move PV gate op emulation code

>>> On 08.06.17 at 19:11, wrote: > --- a/xen/include/asm-x86/pv/traps.h > +++ b/xen/include/asm-x86/pv/traps.h > @@ -26,10 +26,12 @@ > #include > > int pv_emulate_privileged_op(struct cpu_user_regs *regs); > +void pv_emulate_gate_op(struct cpu_user_regs *regs); > >

Re: [Xen-devel] [PATCH v4 02/27] x86: move PV privileged instruction emulation code

>>> On 08.06.17 at 19:11, wrote: > Move the code to pv/emul-priv-op.c. Prefix emulate_privileged_op with > pv_ and export it via pv/traps.h. > > Also move gpr_switch.S since it is used by the privileged instruction > emulation code only. > > Code motion only except for the

Re: [Xen-devel] [PATCH v4 01/27] x86: factor out common PV emulation code

>>> On 08.06.17 at 19:11, wrote: > We're going to split PV emulation code into several files. This patch > extracts the functions needed by them into a dedicated file. > > The functions are now prefixed with "pv_emul_" and exported via a > local header file. > > While at

Re: [Xen-devel] [PATCH v4 11/18] xen/pvcalls: implement accept command

> static void __pvcalls_back_accept(struct work_struct *work) > { > + struct sockpass_mapping *mappass = container_of( > + work, struct sockpass_mapping, register_work); > + struct sock_mapping *map; > + struct pvcalls_ioworker *iow; > + struct pvcalls_fedata

Re: [Xen-devel] [PATCH v1 1/3] livepatch: Add local and global symbol resolution.

On Tue, Jun 20, 2017 at 01:51:41AM -0600, Jan Beulich wrote: > >>> On 20.06.17 at 04:47, wrote: > > This way we can load livepatches with symbol names that > > are the same as long as they are local ('static'). > > > > The use case here is to replace an existing livepatch

Re: [Xen-devel] [PATCH v2] xen: idle_loop: either deal with tasklets or go idle

>>> On 20.06.17 at 15:00, wrote: > In fact, there are two kinds of tasklets: vCPU and > softirq context. When we want to do vCPU context tasklet > work, we force the idle vCPU (of a particular pCPU) into > execution, and run it from there. > > This means there are two

Re: [Xen-devel] [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing

On 6/20/2017 2:38 AM, Borislav Petkov wrote: On Fri, Jun 16, 2017 at 01:51:15PM -0500, Tom Lendacky wrote: Add support to the early boot code to use Secure Memory Encryption (SME). Since the kernel has been loaded into memory in a decrypted state, encrypt the kernel in place and update the

Re: [Xen-devel] [PATCH v4 10/18] xen/pvcalls: implement listen command

On 06/15/2017 03:09 PM, Stefano Stabellini wrote: > Call inet_listen to implement the listen command. > > Signed-off-by: Stefano Stabellini > CC: boris.ostrov...@oracle.com > CC: jgr...@suse.com Reviewed-by: Boris Ostrovsky > --- >

Re: [Xen-devel] [PATCH v4 07/18] xen/pvcalls: implement socket command

On 06/15/2017 03:09 PM, Stefano Stabellini wrote: > Just reply with success to the other end for now. Delay the allocation > of the actual socket to bind and/or connect. > > Signed-off-by: Stefano Stabellini > CC: boris.ostrov...@oracle.com > CC: jgr...@suse.com Reviewed-by:

Re: [Xen-devel] [PATCH v4 08/18] xen/pvcalls: implement connect command

On 06/15/2017 03:09 PM, Stefano Stabellini wrote: > Allocate a socket. Keep track of socket <-> ring mappings with a new data > structure, called sock_mapping. Implement the connect command by calling > inet_stream_connect, and mapping the new indexes page and data ring. > Allocate a workqueue and

Re: [Xen-devel] [PATCH v4 08/18] xen/pvcalls: implement connect command

>> + >> static int pvcalls_back_connect(struct xenbus_device *dev, >> struct xen_pvcalls_request *req) >> { >> +struct pvcalls_fedata *fedata; >> +int ret = -EINVAL; >> +struct socket *sock; >> +struct sock_mapping *map; >> +struct

Re: [Xen-devel] [PATCH v7 14/36] x86/mm: Insure that boot memory areas are mapped properly

On Fri, Jun 16, 2017 at 01:52:32PM -0500, Tom Lendacky wrote: > The boot data and command line data are present in memory in a decrypted > state and are copied early in the boot process. The early page fault > support will map these areas as encrypted, so before attempting to copy > them, add

Re: [Xen-devel] [PATCH v1 OSSTEST 3/3] ts-livepatch: Expand testcase to include global/local symbols

Konrad Rzeszutek Wilk writes ("[PATCH v1 OSSTEST 3/3] ts-livepatch: Expand testcase to include global/local symbols"): > testing. The test is to verify that the local symbols > of payloads are ignored during loading. Can we do this with substeps rather than a conditional test execution ? For

Re: [Xen-devel] [PATCH v3 2/9] x86/ecam: add handlers for the PVH Dom0 MMCFG areas

On Tue, Jun 20, 2017 at 07:14:07AM -0600, Jan Beulich wrote: > >>> On 20.06.17 at 13:56, wrote: > > On Fri, May 19, 2017 at 07:25:22AM -0600, Jan Beulich wrote: > >> >>> On 27.04.17 at 16:35, wrote: > >> > +{ > >> > +unsigned int i; > >> > +int

Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.14

On Tue, Jun 20, 2017 at 07:11:01AM -0600, Jens Axboe wrote: > On 06/20/2017 06:13 AM, Konrad Rzeszutek Wilk wrote: > > Hey Jens, > > > > Please git pull the following branch: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git > > stable/for-jens-4.12 > > > > which has

Re: [Xen-devel] [PATCH] memory: don't suppress P2M update in populate_physmap()

On 06/20/2017 02:03 PM, Jan Beulich wrote: On 20.06.17 at 14:51, wrote: On 06/20/2017 01:40 PM, Andrew Cooper wrote: On 20/06/17 13:39, Julien Grall wrote: On 06/20/2017 09:37 AM, Andrew Cooper wrote: On 20/06/17 07:19, Jan Beulich wrote: Commit d18627583d ("memory:

Re: [Xen-devel] [PATCH v2 09/20] rbtree: adjust root color in rb_insert_color() only when necessary

On Tue, 2017-06-20 at 01:26 -0600, Jan Beulich wrote: > > > > On 19.06.17 at 19:13, wrote: > > And here we are again. (I.e., in the cited Linux's commit, this is > > being turned into 'while (true) {`. > > > > So, I think we should gather others' opinion about how to

Re: [Xen-devel] [PATCH v2 1/3] libxl: add PV display device driver interface

On Thu, May 25, 2017 at 03:17:29PM +0300, Oleksandr Grytsov wrote: > From: Oleksandr Grytsov > I'm sorry, patch like this is impossible to review because: 1. there is no commit message 2. it is huge. I can see it is adding a lot of hooks to the device handling

[Xen-devel] [PATCH 2/3] xen-disk: add support for multi-page shared rings

The blkif protocol has had provision for negotiation of multi-page shared rings for some time now and many guest OS have support in their frontend drivers. This patch makes the necessary modifications to xen-disk support a shared ring up to order 4 (i.e. 16 pages). Signed-off-by: Paul Durrant

[Xen-devel] Synoptek extended outage - Xen Project Massachusetts test lab

Our test and CI facility has been off the internet since approximately 0100 UTC last night. This is due to a complete outage of the Synoptek datacentre on Boston Post Road West, in Marlborough, MA. One of our support staff went to the datacentre and reports: I came on site to speak to him

[Xen-devel] [PATCH 3/3] xen-disk: use an IOThread per instance

This patch allocates an IOThread object for each xen_disk instance and sets the AIO context appropriately on connect. This allows processing of I/O to proceed in parallel. The patch also adds tracepoints into xen_disk to make it possible to follow the state transtions of an instance in the log.

[Xen-devel] [PATCH 0/3] xen-disk: performance improvements

Paul Durrant (3): xen-disk: only advertize feature-persistent if grant copy is not available xen-disk: add support for multi-page shared rings xen-disk: use an IOThread per instance hw/block/trace-events | 7 ++ hw/block/xen_disk.c | 200

[Xen-devel] [PATCH 1/3] xen-disk: only advertize feature-persistent if grant copy is not available

If grant copy is available then it will always be used in preference to persistent maps. In this case feature-persistent should not be advertized to the frontend, otherwise it may needlessly copy data into persistently granted buffers. Signed-off-by: Paul Durrant --- Cc:

Re: [Xen-devel] Implementation of single-stepping for Xen on ARMv7

On 06/19/2017 01:59 PM, Florian Jakobsmeier wrote: Hello Julien, Hi Florian, Please try to configure your e-mail client to quote using '>' rather than tabulation. This is easier to follow the discussion. thank you for your answer and sorry for the delay. 2017-06-14 14:26 GMT+02:00

Re: [Xen-devel] [PATCH 1/2] xen/livepatch: Clean up arch relocation handling

On Tue, Jun 20, 2017 at 01:56:28AM -0600, Jan Beulich wrote: > >>> On 20.06.17 at 09:39, wrote: > > On 20/06/2017 08:36, Jan Beulich wrote: > > On 19.06.17 at 20:18, wrote: > >>> On Wed, Jun 14, 2017 at 07:28:39PM +0100, Andrew Cooper wrote:

Re: [Xen-devel] [PATCH 2/2] xen/livepatch: Don't crash on encountering STN_UNDEF relocations

On Tue, Jun 20, 2017 at 01:15:18AM -0600, Jan Beulich wrote: > >>> On 20.06.17 at 01:05, wrote: > > On 19/06/2017 19:30, Konrad Rzeszutek Wilk wrote: > >> On Wed, Jun 14, 2017 at 12:49:21PM -0600, Jan Beulich wrote: > >> Andrew Cooper

Re: [Xen-devel] preparations 4.7.3 and 4.6.6

Hi all, I am not going to be able to do the website work until Monday, as travelling until late Friday Lars On 20/06/2017, 20:51, "Wei Liu" wrote: >On Fri, Jun 09, 2017 at 06:07:56AM -0600, Jan Beulich wrote: >> All, >> >> with the goal of releasing in about 3 weeks time,

Re: [Xen-devel] clean up and modularize arch dma_mapping interface

On Tue, Jun 20, 2017 at 11:19:02AM +0200, Daniel Vetter wrote: > Ack for the 2 drm patches, but I can also pick them up through drm-misc if > you prefer that (but then it'll be 4.14). Nah, I'll plan to set up a dma-mapping tree so that we'll have common place for dma-mapping work.

Re: [Xen-devel] new dma-mapping tree, was Re: clean up and modularize arch dma_mapping interface V2

On Tue, Jun 20, 2017 at 11:04:00PM +1000, Stephen Rothwell wrote: > git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git#dma-mapping-next > > Contacts: Marek Szyprowski and Kyungmin Park (cc'd) > > I have called your tree dma-mapping-hch for now. The other tree has > not been updated

Re: [Xen-devel] new dma-mapping tree, was Re: clean up and modularize arch dma_mapping interface V2

On Tue, Jun 20, 2017 at 02:14:36PM +0100, Robin Murphy wrote: > Hi Christoph, > > On 20/06/17 13:41, Christoph Hellwig wrote: > > On Fri, Jun 16, 2017 at 08:10:15PM +0200, Christoph Hellwig wrote: > >> I plan to create a new dma-mapping tree to collect all this work. > >> Any volunteers for

Re: [Xen-devel] new dma-mapping tree, was Re: clean up and modularize arch dma_mapping interface V2

Hi Christoph, On 20/06/17 13:41, Christoph Hellwig wrote: > On Fri, Jun 16, 2017 at 08:10:15PM +0200, Christoph Hellwig wrote: >> I plan to create a new dma-mapping tree to collect all this work. >> Any volunteers for co-maintainers, especially from the iommu gang? > > Ok, I've created the new

Re: [Xen-devel] [PATCH v3 2/9] x86/ecam: add handlers for the PVH Dom0 MMCFG areas

>>> On 20.06.17 at 13:56, wrote: > On Fri, May 19, 2017 at 07:25:22AM -0600, Jan Beulich wrote: >> >>> On 27.04.17 at 16:35, wrote: >> > +{ >> > +unsigned int i; >> > +int rc; >> > + >> > +for ( i = 0; i < pci_mmcfg_config_num; i++ ) >> > +

Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.14

On 06/20/2017 06:13 AM, Konrad Rzeszutek Wilk wrote: > Hey Jens, > > Please git pull the following branch: > > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git > stable/for-jens-4.12 > > which has security and memory leak fixes in xen block driver. for-jens-3.14? Anyway, looks

Re: [Xen-devel] new dma-mapping tree, was Re: clean up and modularize arch dma_mapping interface V2

Hi Christoph, On Tue, 20 Jun 2017 14:41:40 +0200 Christoph Hellwig wrote: > > On Fri, Jun 16, 2017 at 08:10:15PM +0200, Christoph Hellwig wrote: > > I plan to create a new dma-mapping tree to collect all this work. > > Any volunteers for co-maintainers, especially from the iommu

Re: [Xen-devel] [PATCH] memory: don't suppress P2M update in populate_physmap()

>>> On 20.06.17 at 14:51, wrote: > On 06/20/2017 01:40 PM, Andrew Cooper wrote: >> On 20/06/17 13:39, Julien Grall wrote: >>> On 06/20/2017 09:37 AM, Andrew Cooper wrote: On 20/06/17 07:19, Jan Beulich wrote: > Commit d18627583d ("memory: don't hand MFN info to

[Xen-devel] [PATCH v2] xen: idle_loop: either deal with tasklets or go idle

In fact, there are two kinds of tasklets: vCPU and softirq context. When we want to do vCPU context tasklet work, we force the idle vCPU (of a particular pCPU) into execution, and run it from there. This means there are two possible reasons for choosing to run the idle vCPU: 1) we want a pCPU to

Re: [Xen-devel] preparations 4.7.3 and 4.6.6

On Fri, Jun 09, 2017 at 06:07:56AM -0600, Jan Beulich wrote: > All, > > with the goal of releasing in about 3 weeks time, please point out > backport candidates you find missing from the respective staging > branches, but which you consider relevant. Please note that 4.6.6 > is expected to be the

Re: [Xen-devel] [PATCH] memory: don't suppress P2M update in populate_physmap()

Hi, On 06/20/2017 01:40 PM, Andrew Cooper wrote: On 20/06/17 13:39, Julien Grall wrote: Hi, On 06/20/2017 09:37 AM, Andrew Cooper wrote: On 20/06/17 07:19, Jan Beulich wrote: Commit d18627583d ("memory: don't hand MFN info to translated guests") wrongly added a null-handle check there -

Re: [Xen-devel] [PATCH v4 1/2] x86/monitor: add masking support for write_ctrlreg events

On Mon, Jun 19, 2017 at 03:24:38PM +0300, Petre Pircalabu wrote: > Add support for filtering out the write_ctrlreg monitor events if they > are generated only by changing certains bits. > A new parameter (bitmask) was added to the xc_monitor_write_ctrlreg > function in order to mask the event

[Xen-devel] new dma-mapping tree, was Re: clean up and modularize arch dma_mapping interface V2

On Fri, Jun 16, 2017 at 08:10:15PM +0200, Christoph Hellwig wrote: > I plan to create a new dma-mapping tree to collect all this work. > Any volunteers for co-maintainers, especially from the iommu gang? Ok, I've created the new tree: git://git.infradead.org/users/hch/dma-mapping.git for-next

Re: [Xen-devel] [PATCH] memory: don't suppress P2M update in populate_physmap()

On 20/06/17 13:39, Julien Grall wrote: > Hi, > > On 06/20/2017 09:37 AM, Andrew Cooper wrote: >> On 20/06/17 07:19, Jan Beulich wrote: >>> Commit d18627583d ("memory: don't hand MFN info to translated guests") >>> wrongly added a null-handle check there - just like stated in its >>> description

Re: [Xen-devel] [PATCH] memory: don't suppress P2M update in populate_physmap()

Hi, On 06/20/2017 09:37 AM, Andrew Cooper wrote: On 20/06/17 07:19, Jan Beulich wrote: Commit d18627583d ("memory: don't hand MFN info to translated guests") wrongly added a null-handle check there - just like stated in its description for memory_exchange(), the array is also an input for

[Xen-devel] Xen Security Advisory 216 - blkif responses leak backend stack data

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-216 version 4 blkif responses leak backend stack data UPDATES IN VERSION 4 Move "For patch:" Reported-by to patches as intended.

[Xen-devel] [GIT PULL] (xen) stable/for-jens-3.14

Hey Jens, Please git pull the following branch: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-4.12 which has security and memory leak fixes in xen block driver. Thank you. Jan Beulich (1): xen-blkback: don't leak stack data via response ring Juergen

[Xen-devel] [PATCH] xen/disk: don't leak stack data via response ring

Rather than constructing a local structure instance on the stack, fill the fields directly on the shared ring, just like other (Linux) backends do. Build on the fact that all response structure flavors are actually identical (the old code did make this assumption too). This is XSA-216. Reported

[Xen-devel] Xen Security Advisory 218 - Races in the grant table unmap code

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-218 version 4 Races in the grant table unmap code UPDATES IN VERSION 4 Adjust last patch description and add review tag. Public

[Xen-devel] Xen Security Advisory 223 - ARM guest disabling interrupt may crash Xen

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-223 version 2 ARM guest disabling interrupt may crash Xen UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION =

[Xen-devel] Xen Security Advisory 216 - blkif responses leak backend stack data

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-216 version 3 blkif responses leak backend stack data UPDATES IN VERSION 3 Public release. Fix a typo ("our" for "or" in Vulnerable

  1   2   >