Re: [Xen-devel] [PATCH v3 2/3] x86/svm: Drop enum instruction_index and simplify svm_get_insn_len()

>>> On 31.01.19 at 19:07, wrote: > On 07/01/2019 10:30, Jan Beulich wrote: > On 31.12.18 at 12:37, wrote: >>> Passing a 32-bit integer index into an array with entries containing less >>> than >>> 32 bits of data is wasteful, and creates an unnecessary error condition of >>> passing an

Re: [Xen-devel] [PATCH] x86/pv: Enable pv-l1tf mitigations for dom0 by default

>>> On 31.01.19 at 18:19, wrote: > On 31/01/2019 16:54, Jan Beulich wrote: > On 31.01.19 at 17:35, wrote: >>> On 31/01/2019 14:25, Jan Beulich wrote: >>> On 31.01.19 at 14:59, wrote: > At the time XSA-273 was published, shadowing dom0 had proved to be > unstable, > which is

[Xen-devel] Scheduling and the periodic timer

While working on my core scheduling series I stumbled over the periodic timer. Could it be this timer never worked correctly? When the vcpu with an active periodic timer is running everything seems to be fine. But when not running the timer is stopped in schedule(). So a vcpu going to idle

Re: [Xen-devel] [PATCH v3 0/3] x86/svm: Improvements to SVM instruction length handling

On 31/01/2019 17:56, Andrew Cooper wrote: > On 31/12/2018 11:37, Andrew Cooper wrote: >> The main bugfix in v2 of this series has now been committed, leaving just the >> cleanup remaining. See patches for details. >> >> Andrew Cooper (3): >> x86/svm: Remove list functionality from

Re: [Xen-devel] [PATCH v6 14/27] x86/percpu: Adapt percpu for PIE support

On Thu, 31 Jan 2019, Thomas Garnier wrote: > The per-cpu symbols are in a section that is zero based to create > offsets. The compiler doesn't see them as offsets but as relative > symbol and try to relocate them. Given the distance between zero and > the mapped kernel is much larger than the

[Xen-devel] [xen-4.10-testing test] 132630: tolerable FAIL - PUSHED

flight 132630 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/132630/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail in 132577 pass in 132630

Re: [Xen-devel] RT Xen on ARM - R-Car series

Hi Stefano, On 1/31/19 9:56 PM, Stefano Stabellini wrote: On Thu, 31 Jan 2019, Julien Grall wrote: On 31/01/2019 12:00, Andrii Anisov wrote: Hello Julien, On 31.01.19 13:37, Julien Grall wrote: On my side I just commented out that printk, because it renders a debug build unusable. ... if

Re: [Xen-devel] [PATCH v6 00/27] x86: PIE support and option to extend KASLR randomization

On Thu, Jan 31, 2019 at 1:41 PM Konrad Rzeszutek Wilk wrote: > > On Thu, Jan 31, 2019 at 11:24:07AM -0800, Thomas Garnier wrote: > > There has been no major concern in the latest iterations. I am interested on > > what would be the best way to slowly integrate this patchset upstream. > > One

Re: [Xen-devel] [PATCH v6 14/27] x86/percpu: Adapt percpu for PIE support

On Thu, Jan 31, 2019 at 12:57 PM Christopher Lameter wrote: > > On Thu, 31 Jan 2019, Thomas Garnier wrote: > > > Perpcu uses a clever design where the .percu ELF section has a virtual > > address of zero and the custom linux relocation code avoid relocating > > specific symbols. It makes the code

Re: [Xen-devel] [PATCH SpectreV1+L1TF v4 03/11] config: introduce L1TF_LFENCE option

On 25/01/2019 10:14, Jan Beulich wrote: On 24.01.19 at 22:29, wrote: >> Worse is the "evaluate condition, stash result, fence, use variable" >> option, which is almost completely useless. If you work out the >> resulting instruction stream, you'll have a conditional expression >> calculated

Re: [Xen-devel] RT Xen on ARM - R-Car series

On Thu, 31 Jan 2019, Julien Grall wrote: > On 31/01/2019 12:00, Andrii Anisov wrote: > > Hello Julien, > > > > On 31.01.19 13:37, Julien Grall wrote: > > > > On my side I just commented out that printk, because it renders a debug > > > > build unusable. > > > > > > ... if it is unusable, why

Re: [Xen-devel] xen/mem-reservation API and out-of-tree kernel modules

On Thu, 31 Jan 2019, Oleksandr Andrushchenko wrote: > Hello, > > I am working on porting an out-of-tree kernel driver to the kernel > 5.0 and that driver uses functionality provided by > drivers/xen/mem-reservation.c > module.  Since commit [1] it is not possible to build a kernel module > which

Re: [Xen-devel] [PATCH v6 00/27] x86: PIE support and option to extend KASLR randomization

On Thu, Jan 31, 2019 at 11:24:07AM -0800, Thomas Garnier wrote: > There has been no major concern in the latest iterations. I am interested on > what would be the best way to slowly integrate this patchset upstream. One question that I was somehow expected in this cover letter - what about all

Re: [Xen-devel] [PATCH v6 14/27] x86/percpu: Adapt percpu for PIE support

On Thu, 31 Jan 2019, Thomas Garnier wrote: > Perpcu uses a clever design where the .percu ELF section has a virtual > address of zero and the custom linux relocation code avoid relocating > specific symbols. It makes the code simple and easily adaptable with or > without SMP support. We usually

[Xen-devel] [xen-unstable test] 132622: tolerable FAIL - PUSHED

flight 132622 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/132622/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 132422

Re: [Xen-devel] [PATCH SpectreV1+L1TF v5 3/9] x86/hvm: block speculative out-of-bound accesses

On 31/01/2019 16:19, Jan Beulich wrote: > >> @@ -4104,6 +4108,12 @@ static int hvmop_set_param( >> if ( a.index >= HVM_NR_PARAMS ) >> return -EINVAL; >> >> +/* >> + * Make sure the guest controlled value a.index is bounded even during >> + * speculative execution. >> +

Re: [Xen-devel] [PATCH v6 00/27] x86: PIE support and option to extend KASLR randomization

On Fri, Feb 1, 2019 at 8:28 AM Thomas Garnier wrote: > These patches make the changes necessary to build the kernel as Position > Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below > the top 2G of the virtual address space. It allows to optionally extend the > KASLR

[Xen-devel] unsubscribe

From: Hook, Gary Sent: Wednesday, January 30, 2019 3:36 PM To: xen-devel@lists.xenproject.org Subject: unsubscribe ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH SpectreV1+L1TF v4 04/11] x86/hvm: block speculative out-of-bound accesses

On 23/01/2019 11:51, Norbert Manthey wrote: > There are multiple arrays in the HVM interface that are accessed > with indices that are provided by the guest. To avoid speculative > out-of-bound accesses, we use the array_index_nospec macro. > > When blocking speculative out-of-bound accesses, we

[Xen-devel] [PATCH v6 00/27] x86: PIE support and option to extend KASLR randomization

There has been no major concern in the latest iterations. I am interested on what would be the best way to slowly integrate this patchset upstream. Changes: - patch v6: - Rebase on latest changes in jump tables and crypto. - Fix wording on couple commits. - Revisit checkpatch warnings.

[Xen-devel] [PATCH v6 18/27] xen: Adapt assembly for PIE support

Change the assembly code to use the new _ASM_MOVABS macro which get a symbol reference while being PIE compatible. Adapt the relocation tool to ignore 32-bit Xen code. Position Independent Executable (PIE) support will allow to extend the KASLR randomization range below 0x8000.

[Xen-devel] [PATCH v6 14/27] x86/percpu: Adapt percpu for PIE support

Perpcu uses a clever design where the .percu ELF section has a virtual address of zero and the custom linux relocation code avoid relocating specific symbols. It makes the code simple and easily adaptable with or without SMP support. This design is incompatible with PIE. While creating a PIE

Re: [Xen-devel] [PATCH for-4.12 v4 2/3] x86/svm: Drop enum instruction_index and simplify svm_get_insn_len()

On 1/31/19 12:24 PM, Andrew Cooper wrote: > Passing a 32-bit integer index into an array with entries containing less than > 32 bits of data is wasteful, and creates an unnecessary error condition of > passing an out-of-range index. > > The width of the X86EMUL_OPC() encoding is currently 20 bits

Re: [Xen-devel] [PATCH v3 2/3] x86/svm: Drop enum instruction_index and simplify svm_get_insn_len()

On 07/01/2019 10:30, Jan Beulich wrote: On 31.12.18 at 12:37, wrote: >> Passing a 32-bit integer index into an array with entries containing less >> than >> 32 bits of data is wasteful, and creates an unnecessary error condition of >> passing an out-of-range index. >> >> The width of the

[Xen-devel] [PATCH for-4.12 v4 2/3] x86/svm: Drop enum instruction_index and simplify svm_get_insn_len()

Passing a 32-bit integer index into an array with entries containing less than 32 bits of data is wasteful, and creates an unnecessary error condition of passing an out-of-range index. The width of the X86EMUL_OPC() encoding is currently 20 bits for the instructions used, which leaves room for a

[Xen-devel] [linux-next test] 132614: regressions - FAIL

flight 132614 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/132614/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 132599

Re: [Xen-devel] [PATCH v2 for-4.12] libxl: When restricted, start QEMU paused

Anthony PERARD writes ("[PATCH v2 for-4.12] libxl: When restricted, start QEMU paused"): > Signed-off-by: Anthony PERARD > Release-acked-by: Juergen Gross Acked-by: Ian Jackson ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

Re: [Xen-devel] [PATCH for-4.12 1/8] dom0/pvh: align allocation and mapping order to start address

On Wed, Jan 30, 2019 at 02:58:42PM +0100, Roger Pau Monné wrote: > On Wed, Jan 30, 2019 at 12:37:28PM +, Wei Liu wrote: > > On Wed, Jan 30, 2019 at 11:36:39AM +0100, Roger Pau Monne wrote: > > > Due to the recent changes in the iommu mapping logic, the start > > > addresses provided need to be

Re: [Xen-devel] [PATCH] x86/pv: Enable pv-l1tf mitigations for dom0 by default

On 31/01/2019 16:54, Jan Beulich wrote: On 31.01.19 at 17:35, wrote: >> On 31/01/2019 14:25, Jan Beulich wrote: >> On 31.01.19 at 14:59, wrote: At the time XSA-273 was published, shadowing dom0 had proved to be unstable, which is why dom0 was unprotected by default. The

Re: [Xen-devel] [PATCH 6/8] x86/mm: split p2m ioreq server pages special handling into helper

On Thu, Jan 31, 2019 at 03:59:50PM +0100, Paul Durrant wrote: > > -Original Message- > > From: Roger Pau Monne [mailto:roger@citrix.com] > > Sent: 30 January 2019 10:37 > > To: xen-devel@lists.xenproject.org > > Cc: Roger Pau Monne ; George Dunlap > > ; Jan Beulich ; Andrew Cooper > >

Re: [Xen-devel] [PATCH] x86/pv: Enable pv-l1tf mitigations for dom0 by default

>>> On 31.01.19 at 17:35, wrote: > On 31/01/2019 14:25, Jan Beulich wrote: > On 31.01.19 at 14:59, wrote: >>> At the time XSA-273 was published, shadowing dom0 had proved to be unstable, >>> which is why dom0 was unprotected by default. The instability was > identified >>> to be problems

Re: [Xen-devel] [PATCH v7 09/15] argo: implement the sendv op; evtchn: expose send_guest_global_virq

>>> On 31.01.19 at 17:35, wrote: > On Wed, Jan 30, 2019 at 08:28:14PM -0800, Christopher Clark wrote: >> +static int >> +ringbuf_insert(const struct domain *d, struct argo_ring_info *ring_info, >> + const struct argo_ring_id *src_id, xen_argo_iov_t *iovs, >> + unsigned

Re: [Xen-devel] [PATCH v3 0/3] x86/svm: Improvements to SVM instruction length handling

On 31/12/2018 11:37, Andrew Cooper wrote: > The main bugfix in v2 of this series has now been committed, leaving just the > cleanup remaining. See patches for details. > > Andrew Cooper (3): > x86/svm: Remove list functionality from __get_instruction_length_* > infrastructure > x86/svm: Drop

Re: [Xen-devel] [PATCH v7 10/15] argo: implement the notify op

On Wed, Jan 30, 2019 at 08:28:15PM -0800, Christopher Clark wrote: > Queries for data about space availability in registered rings and > causes notification to be sent when space has become available. > > The hypercall op populates a supplied data structure with information about > ring state and

Re: [Xen-devel] [PATCH v3 1/3] x86/svm: Remove list functionality from __get_instruction_length_* infrastructure

On 12/31/18 5:37 AM, Andrew Cooper wrote: > The existing __get_instruction_length_from_list() has a single user > which uses the list functionality. That user however should be looking > specifically for INVD or WBINVD, as reported by the vmexit exit reason. > > Modify

Re: [Xen-devel] [PATCH v7 15/15] MAINTAINERS: add new section for Argo and self as maintainer

On Wed, Jan 30, 2019 at 08:28:20PM -0800, Christopher Clark wrote: > Signed-off-by: Christopher Clark Reviewed-by: Roger Pau Monné ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 1/4] x86emul: avoid speculative out of bounds accesses

>>> On 31.01.19 at 17:14, wrote: > On 31/01/2019 15:50, Jan Beulich wrote: > On 31.01.19 at 15:54, wrote: >>> On 31/01/2019 14:25, Jan Beulich wrote: --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -2207,10 +2207,7 @@ static void

Re: [Xen-devel] [PATCH v7 09/15] argo: implement the sendv op; evtchn: expose send_guest_global_virq

On Wed, Jan 30, 2019 at 08:28:14PM -0800, Christopher Clark wrote: > sendv operation is invoked to perform a synchronous send of buffers > contained in iovs to a remote domain's registered ring. > > It takes: > * A destination address (domid, port) for the ring to send to. >It performs a

Re: [Xen-devel] [PATCH] x86/pv: Enable pv-l1tf mitigations for dom0 by default

On 31/01/2019 14:25, Jan Beulich wrote: On 31.01.19 at 14:59, wrote: >> At the time XSA-273 was published, shadowing dom0 had proved to be unstable, >> which is why dom0 was unprotected by default. The instability was identified >> to be problems with shadowing PV superpages, and fixed. >>

Re: [Xen-devel] [PATCH v7 04/15] argo: init, destroy and soft-reset, with enable command line opt

>>> On 31.01.19 at 17:05, wrote: > On Thu, Jan 31, 2019 at 08:13:27AM -0700, Jan Beulich wrote: >> >>> On 31.01.19 at 15:49, wrote: >> > On Wed, Jan 30, 2019 at 08:28:09PM -0800, Christopher Clark wrote: >> >> +static void >> >> +pending_remove_all(const struct domain *d, struct argo_ring_info

Re: [Xen-devel] [PATCH SpectreV1+L1TF v5 4/9] spec: add l1tf-barrier

>>> On 29.01.19 at 15:43, wrote: > @@ -1942,6 +1942,12 @@ Irrespective of Xen's setting, the feature is > virtualised for HVM guests to > use. By default, Xen will enable this mitigation on hardware believed to > be > vulnerable to L1TF. > > +On hardware vulnerable to L1TF, the

Re: [Xen-devel] [PATCH v7 07/15] argo: implement the register op

On Wed, Jan 30, 2019 at 08:28:12PM -0800, Christopher Clark wrote: > The register op is used by a domain to register a region of memory for > receiving messages from either a specified other domain, or, if specifying a > wildcard, any domain. > > This operation creates a mapping within Xen's

Re: [Xen-devel] [PATCH SpectreV1+L1TF v5 3/9] x86/hvm: block speculative out-of-bound accesses

>>> On 29.01.19 at 15:43, wrote: > There are multiple arrays in the HVM interface that are accessed > with indices that are provided by the guest. To avoid speculative > out-of-bound accesses, we use the array_index_nospec macro. > > When blocking speculative out-of-bound accesses, we can

Re: [Xen-devel] [PATCH v7 04/15] argo: init, destroy and soft-reset, with enable command line opt

On Thu, Jan 31, 2019 at 08:13:27AM -0700, Jan Beulich wrote: > >>> On 31.01.19 at 15:49, wrote: > > On Wed, Jan 30, 2019 at 08:28:09PM -0800, Christopher Clark wrote: > >> +static struct argo_ring_info * > >> +find_ring_info(const struct domain *d, const struct argo_ring_id *id) > >> +{ > >> +

Re: [Xen-devel] [PATCH SpectreV1+L1TF v5 2/9] x86/vioapic: block speculative out-of-bound accesses

>>> On 29.01.19 at 15:43, wrote: > When interacting with io apic, a guest can specify values that are used > as index to structures, and whose values are not compared against > upper bounds to prevent speculative out-of-bound accesses. This change > prevents these speculative accesses. > >

Re: [Xen-devel] [PATCH v7 01/28] linkage: new macros for assembler symbols

On Wed, Jan 30, 2019 at 01:46:44PM +0100, Jiri Slaby wrote: > Introduce new C macros for annotations of functions and data in > assembly. There is a long-standing mess in macros like ENTRY, END, > ENDPROC and similar. They are used in different manners and sometimes > incorrectly. > > So

Re: [Xen-devel] [PATCH 03/14] AMD/IOMMU: Fix multiple reference counting errors

On 11/21/18 7:21 AM, Andrew Cooper wrote: > Most of these issues would be XSAs if these paths were accessible to guests. > > First, override the {get,put}_gfn() helpers to use gfn_t, which was the > original purpose of this patch. > > guest_iommu_get_table_mfn() has two bugs. First, it gets a

Re: [Xen-devel] [PATCH v3] xen-block: handle resize callback

On Thu, Jan 31, 2019 at 03:33:16PM +, Paul Durrant wrote: > Some frontend drivers will handle dynamic resizing of PV disks, so set up > the BlockDevOps resize_cb() method during xen_block_realize() to allow > this to be done. > > Signed-off-by: Paul Durrant Reviewed-by: Anthony PERARD

Re: [Xen-devel] [PATCH 1/4] x86emul: avoid speculative out of bounds accesses

>>> On 31.01.19 at 15:54, wrote: > On 31/01/2019 14:25, Jan Beulich wrote: >> --- a/xen/arch/x86/x86_emulate/x86_emulate.c >> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c >> @@ -2207,10 +2207,7 @@ static void *_decode_gpr( >> >> ASSERT(modrm_reg < ARRAY_SIZE(byte_reg_offsets)); >> >> -

Re: [Xen-devel] [PATCH v2] xen-block: handle resize callback

> -Original Message- > From: Anthony PERARD [mailto:anthony.per...@citrix.com] > Sent: 31 January 2019 15:25 > To: Paul Durrant > Cc: qemu-de...@nongnu.org; qemu-bl...@nongnu.org; xen- > de...@lists.xenproject.org; Stefan Hajnoczi ; Stefano > Stabellini ; Kevin Wolf ; Max > Reitz >

Re: [Xen-devel] [PATCH v2] xen-block: handle resize callback

> -Original Message- > From: Anthony PERARD [mailto:anthony.per...@citrix.com] > Sent: 31 January 2019 15:21 > To: Paul Durrant > Cc: qemu-de...@nongnu.org; qemu-bl...@nongnu.org; xen- > de...@lists.xenproject.org; Stefan Hajnoczi ; Stefano > Stabellini ; Kevin Wolf ; Max > Reitz >

Re: [Xen-devel] [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()

On Mon, Jan 21, 2019 at 12:06 AM Mike Rapoport wrote: > > Add check for the return value of memblock_alloc*() functions and call > panic() in case of error. > The panic message repeats the one used by panicing memblock allocators with > adjustment of parameters to include only relevant ones. > >

Re: [Xen-devel] [PATCH v2] xen-block: handle resize callback

On Thu, Jan 31, 2019 at 03:22:18PM +, Paul Durrant wrote: > > -Original Message- > > From: Anthony PERARD [mailto:anthony.per...@citrix.com] > > Sent: 31 January 2019 15:21 > > To: Paul Durrant > > Cc: qemu-de...@nongnu.org; qemu-bl...@nongnu.org; xen- > > de...@lists.xenproject.org;

Re: [Xen-devel] [PATCH v2] xen-block: handle resize callback

On Wed, Jan 30, 2019 at 04:19:48PM +, Paul Durrant wrote: > Some frontend drivers will handle dynamic resizing of PV disks, so set up > the BlockDevOps resize_cb() method during xen_block_realize() to allow > this to be done. > > Signed-off-by: Paul Durrant > --- > +/* > + * Mimic

Re: [Xen-devel] [PATCH v7 04/15] argo: init, destroy and soft-reset, with enable command line opt

>>> On 31.01.19 at 15:49, wrote: > On Wed, Jan 30, 2019 at 08:28:09PM -0800, Christopher Clark wrote: >> +static struct argo_ring_info * >> +find_ring_info(const struct domain *d, const struct argo_ring_id *id) >> +{ >> +struct argo_ring_info *ring_info; >> +const struct list_head

Re: [Xen-devel] [PATCH SpectreV1+L1TF v5 1/9] xen/evtchn: block speculative out-of-bound accesses

>>> On 29.01.19 at 15:43, wrote: > --- a/xen/common/event_channel.c > +++ b/xen/common/event_channel.c > @@ -365,11 +365,16 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, > evtchn_port_t port) > if ( (virq < 0) || (virq >= ARRAY_SIZE(v->virq_to_evtchn)) ) > return -EINVAL; > >

Re: [Xen-devel] [PATCH 6/8] x86/mm: split p2m ioreq server pages special handling into helper

> -Original Message- > From: Roger Pau Monne [mailto:roger@citrix.com] > Sent: 30 January 2019 10:37 > To: xen-devel@lists.xenproject.org > Cc: Roger Pau Monne ; George Dunlap > ; Jan Beulich ; Andrew Cooper > ; Wei Liu ; Jun Nakajima > ; Kevin Tian ; Paul Durrant > > Subject: [PATCH

Re: [Xen-devel] [PATCH v7 04/15] argo: init, destroy and soft-reset, with enable command line opt

On Wed, Jan 30, 2019 at 08:28:09PM -0800, Christopher Clark wrote: > Initialises basic data structures and performs teardown of argo state > for domain shutdown. > > Inclusion of the Argo implementation is dependent on CONFIG_ARGO. > > Introduces a new Xen command line parameter 'argo': bool to

Re: [Xen-devel] [PATCH] x86/cpuid: correct dependencies of post-SSE ISA extensions

>>> On 31.01.19 at 14:36, wrote: > On 31/01/2019 10:06, Jan Beulich wrote: > On 30.01.19 at 21:21, wrote: >>> On 14/01/2019 12:48, Jan Beulich wrote: >>> On 14.01.19 at 13:00, wrote: > On 14/01/2019 11:39, Jan Beulich wrote: >> First of all a PCLMULQDQ dependency was missing

Re: [Xen-devel] [PATCH v3 3/9] viridian: extend init/deinit hooks into synic and time modules

On Thu, Jan 31, 2019 at 10:47:24AM +, Paul Durrant wrote: > This patch simply adds domain and vcpu init/deinit hooks into the synic > and time modules and wires them into viridian_[domain|vcpu]_[init|deinit](). > Only one of the hooks is currently needed (to unmap the 'VP Assist' page) > but

Re: [Xen-devel] [PATCH v3 8/9] viridian: add implementation of synthetic timers

On Thu, Jan 31, 2019 at 10:47:29AM +, Paul Durrant wrote: > This patch introduces an implementation of the STIMER0-15_CONFIG/COUNT MSRs > and hence a the first SynIC message source. > > The new (and documented) 'stimer' viridian enlightenment group may be > specified to enable this feature. >

Re: [Xen-devel] [PATCH v3 9/9] viridian: add implementation of the HvSendSyntheticClusterIpi hypercall

On Thu, Jan 31, 2019 at 10:47:30AM +, Paul Durrant wrote: > This patch adds an implementation of the hypercall as documented in the > specification [1], section 10.5.2. This enlightenment, as with others, is > advertised by CPUID leaf 0x4004 and is under control of a new > 'hcall_ipi'

Re: [Xen-devel] [PATCH v3 6/9] viridian: add implementation of synthetic interrupt MSRs

On Thu, Jan 31, 2019 at 10:47:27AM +, Paul Durrant wrote: > This patch introduces an implementation of the SCONTROL, SVERSION, SIEFP, > SIMP, EOM and SINT0-15 SynIC MSRs. No message source is added and, as such, > nothing will yet generate a synthetic interrupt. A subsequent patch will > add

[Xen-devel] [PATCH 4/4] x86/vLAPIC: avoid speculative out of bounds accesses

Array indexes used in the MMIO and MSR read/write emulation functions are derived from guest controlled values. Restrict their ranges to limit the side effects of speculative execution. Remove the unused vlapic_lvt_{vector,dm}() instead of adjusting them. Signed-off-by: Jan Beulich ---

[Xen-devel] [PATCH 3/4] x86/vPIC: avoid speculative out of bounds accesses

Array indexes used in the I/O port read/write emulation functions are derived from guest controlled values. Where this is not already done, restrict their ranges to limit the side effects of speculative execution. Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/vpic.c +++

[Xen-devel] [PATCH 2/4] x86/vMSI: avoid speculative out of bounds accesses

Array indexes used in the MMIO read/write emulation functions are derived from guest controlled values. Restrict their ranges to limit the side effects of speculative execution. Note that the index into .msi_ad[] may also be out of bounds, by exactly one (indexes 0...3 are possible while the

[Xen-devel] [PATCH 1/4] x86emul: avoid speculative out of bounds accesses

There are a few array accesses here the indexes of which are (at least indirectly) driven by the guest. Use array_access_nospec() to bound such accesses. In the {,_}decode_gpr() cases replace existing guarding constructs. To deal with an otherwise occurring #include cycle, drop the inclusion of

Re: [Xen-devel] [PATCH] x86/pv: Enable pv-l1tf mitigations for dom0 by default

>>> On 31.01.19 at 14:59, wrote: > At the time XSA-273 was published, shadowing dom0 had proved to be unstable, > which is why dom0 was unprotected by default. The instability was identified > to be problems with shadowing PV superpages, and fixed. > > In hindsight, this patch should have been

Re: [Xen-devel] [PATCH 0/4] x86: further L1TF / XSA-289 guards

On 31/01/2019 15:07, Jan Beulich wrote: > This goes alongside Norbert's series, dealing with a few more > places where I happened to know (without any analysis tools) > guest controlled array accesses sit. I've additionally also > checked emul-i8254.c, and I think no adjustments are needed > there

[Xen-devel] [PATCH 0/4] x86: further L1TF / XSA-289 guards

This goes alongside Norbert's series, dealing with a few more places where I happened to know (without any analysis tools) guest controlled array accesses sit. I've additionally also checked emul-i8254.c, and I think no adjustments are needed there (there are a few possible overruns by one, but

[Xen-devel] xen/mem-reservation API and out-of-tree kernel modules

Hello, I am working on porting an out-of-tree kernel driver to the kernel 5.0 and that driver uses functionality provided by drivers/xen/mem-reservation.c module.  Since commit [1] it is not possible to build a kernel module which uses mem-reservation API as xen_scrub_pages variable, which is

[Xen-devel] [PATCH] x86/pv: Enable pv-l1tf mitigations for dom0 by default

At the time XSA-273 was published, shadowing dom0 had proved to be unstable, which is why dom0 was unprotected by default. The instability was identified to be problems with shadowing PV superpages, and fixed. In hindsight, this patch should have been posted at the same time. There is now no

[Xen-devel] [xen-unstable-smoke test] 132668: tolerable all pass - PUSHED

flight 132668 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/132668/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm

Re: [Xen-devel] [PATCH v5 00/15] Argo: hypervisor-mediated interdomain communication

On Wed, Jan 30, 2019 at 08:05:30PM -0800, Christopher Clark wrote: > On Tue, Jan 22, 2019 at 6:19 AM Roger Pau Monné wrote: > > > > On Mon, Jan 21, 2019 at 01:59:40AM -0800, Christopher Clark wrote: > > > Version five of this patch series: > > > > > > * Changes are primarily addressing feedback

Re: [Xen-devel] [PATCH] x86/cpuid: correct dependencies of post-SSE ISA extensions

On 31/01/2019 10:06, Jan Beulich wrote: On 30.01.19 at 21:21, wrote: >> On 14/01/2019 12:48, Jan Beulich wrote: >> On 14.01.19 at 13:00, wrote: On 14/01/2019 11:39, Jan Beulich wrote: > First of all a PCLMULQDQ dependency was missing entirely. Add it as well > as AESNI and

Re: [Xen-devel] [PATCHv2 1/9] mm: Introduce new vm_insert_range and vm_insert_range_buggy API

Am Donnerstag, 31. Januar 2019, 13:31:52 CET schrieb Souptick Joarder: > On Thu, Jan 31, 2019 at 5:37 PM Heiko Stuebner wrote: > > > > Am Donnerstag, 31. Januar 2019, 04:08:12 CET schrieb Souptick Joarder: > > > Previouly drivers have their own way of mapping range of > > > kernel pages/memory

Re: [Xen-devel] [PATCHv2 1/9] mm: Introduce new vm_insert_range and vm_insert_range_buggy API

On Thu, Jan 31, 2019 at 5:37 PM Heiko Stuebner wrote: > > Am Donnerstag, 31. Januar 2019, 04:08:12 CET schrieb Souptick Joarder: > > Previouly drivers have their own way of mapping range of > > kernel pages/memory into user vma and this was done by > > invoking vm_insert_page() within a loop. > >

Re: [Xen-devel] RT Xen on ARM - R-Car series

(CC Xen-devel) On 31/01/2019 05:50, LOPEZ, FUENTES NACARINO Jairo Eduardo wrote: Hello Julien, Hi, 2019年1月30日(水) 21:12、Julien Grall さん（julien.gr...@arm.com ）のメッセージ: Hi, On 30/01/2019 20:23, LOPEZ, FUENTES NACARINO Jairo Eduardo wrote: My e-mail

[Xen-devel] [freebsd-master test] 132616: all pass - PUSHED

flight 132616 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/132616/ Perfect :-) All tests in this flight passed as required version targeted for testing: freebsd 0ae2e694958b1767ec69d0f76a0d1afceecbcc89 baseline version: freebsd

Re: [Xen-devel] RT Xen on ARM - R-Car series

On 31/01/2019 12:00, Andrii Anisov wrote: Hello Julien, On 31.01.19 13:37, Julien Grall wrote: On my side I just commented out that printk, because it renders a debug build unusable. ... if it is unusable, why don't you try to tackle the problem? Because of... This is in my long ever

Re: [Xen-devel] [PATCHv2 1/9] mm: Introduce new vm_insert_range and vm_insert_range_buggy API

Am Donnerstag, 31. Januar 2019, 04:08:12 CET schrieb Souptick Joarder: > Previouly drivers have their own way of mapping range of > kernel pages/memory into user vma and this was done by > invoking vm_insert_page() within a loop. > > As this pattern is common across different drivers, it can > be

[Xen-devel] [linux-linus test] 132599: tolerable FAIL - PUSHED

flight 132599 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/132599/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt 6 xen-install fail in 132561 pass in 132599 test-armhf-armhf-examine 8

Re: [Xen-devel] RT Xen on ARM - R-Car series

Hello Julien, On 31.01.19 13:37, Julien Grall wrote: On my side I just commented out that printk, because it renders a debug build unusable. ... if it is unusable, why don't you try to tackle the problem? Because of... This is in my long ever growing list of things to ... be done. Some

Re: [Xen-devel] RT Xen on ARM - R-Car series

On 31/01/2019 11:22, Andrii Anisov wrote: Julien, On 30.01.19 14:12, Julien Grall wrote: Hi, On 30/01/2019 20:23, LOPEZ, FUENTES NACARINO Jairo Eduardo wrote: My e-mail client thinks the e-mail was sent from the future. Can you make sure your timezone is set correctly? [    0.682996]

Re: [Xen-devel] RT Xen on ARM - R-Car series

Julien, On 30.01.19 14:12, Julien Grall wrote: Hi, On 30/01/2019 20:23, LOPEZ, FUENTES NACARINO Jairo Eduardo wrote: My e-mail client thinks the e-mail was sent from the future. Can you make sure your timezone is set correctly? [    0.682996] CPU features: detected feature: Kernel page

Re: [Xen-devel] [PATCHv2 1/9] mm: Introduce new vm_insert_range and vm_insert_range_buggy API

On Thu, Jan 31, 2019 at 03:43:39PM +0530, Souptick Joarder wrote: > On Thu, Jan 31, 2019 at 2:09 PM Mike Rapoport wrote: > > > > On Thu, Jan 31, 2019 at 08:38:12AM +0530, Souptick Joarder wrote: > > > Previouly drivers have their own way of mapping range of > > > kernel pages/memory into user vma

Re: [Xen-devel] [PATCH v5 09/15] argo: implement the sendv op; evtchn: expose send_guest_global_virq

On Thu, Jan 31, 2019 at 03:35:23AM -0700, Jan Beulich wrote: > >>> On 31.01.19 at 11:18, wrote: > > On Wed, Jan 30, 2019 at 08:10:28PM -0800, Christopher Clark wrote: > >> On Tue, Jan 22, 2019 at 4:08 AM Roger Pau Monné > >> wrote: > >> > On Mon, Jan 21, 2019 at 01:59:49AM -0800, Christopher

[Xen-devel] [PATCH v2 for-4.12] libxl: When restricted, start QEMU paused

libxl runs the command "cont" later during guest creation; i.e. it is expecting that QEMU would not do any emulation. Use the "-S" command option to achieve this. Unfortunately, when QEMU is started with "-S", it won't write QEMU's readiness into xenstore. So only activate this option when we

[Xen-devel] [PATCH v3 6/9] viridian: add implementation of synthetic interrupt MSRs

This patch introduces an implementation of the SCONTROL, SVERSION, SIEFP, SIMP, EOM and SINT0-15 SynIC MSRs. No message source is added and, as such, nothing will yet generate a synthetic interrupt. A subsequent patch will add an implementation of synthetic timers which will need the

[Xen-devel] [PATCH v3 0/9] viridian: implement more enlightenments

This series adds three new enlightenments: - Synthetic timers, which depends on the... - Synthetic interrupt controller (or SynIC) - Synthetic cluster IPI All these enlightenments are implemented in current versions of QEMU/KVM so this series closes the gap. Paul Durrant (9): viridian: add

[Xen-devel] [PATCH v3 8/9] viridian: add implementation of synthetic timers

This patch introduces an implementation of the STIMER0-15_CONFIG/COUNT MSRs and hence a the first SynIC message source. The new (and documented) 'stimer' viridian enlightenment group may be specified to enable this feature. NOTE: It is necessary for correct operation that timer expiration and

[Xen-devel] [PATCH v3 1/9] viridian: add init hooks

This patch adds domain and vcpu init hooks for viridian features. The init hooks do not yet do anything; the functionality will be added to by subsequent patches. NOTE: This patch also removes the call from the domain deinit function to the vcpu deinit function, as this is not necessary.

[Xen-devel] [PATCH v3 7/9] viridian: stop directly calling viridian_time_ref_count_freeze/thaw()...

...from arch_domain_shutdown/pause/unpause(). A subsequent patch will introduce an implementaion of synthetic timers which will also need freeze/thaw hooks, so make the exported hooks more generic and call through to (re-named and static) time_ref_count_freeze/thaw functions. NOTE: This patch

[Xen-devel] [PATCH v3 3/9] viridian: extend init/deinit hooks into synic and time modules

This patch simply adds domain and vcpu init/deinit hooks into the synic and time modules and wires them into viridian_[domain|vcpu]_[init|deinit](). Only one of the hooks is currently needed (to unmap the 'VP Assist' page) but subsequent patches will make use of the others. NOTE: To perform the

[Xen-devel] [PATCH v3 5/9] viridian: use viridian_map/unmap_guest_page() for reference tsc page

Whilst the reference tsc page does not currently need to be kept mapped after it is initially set up (or updated after migrate), the code can be simplified by using the common guest page map/unmap and dump functions. New functionality added by a subsequent patch will also require the page to kept

[Xen-devel] [PATCH v3 4/9] viridian: add missing context save helpers into synic and time modules

Currently the time module lacks vcpu context save helpers and the synic module lacks domain context save helpers. These helpers are not yet required but subsequent patches will require at least some of them so this patch completes the set to avoid introducing them in an ad-hoc way. Signed-off-by:

[Xen-devel] [PATCH v3 2/9] viridian: separately allocate domain and vcpu structures

Currently the viridian_domain and viridian_vcpu structures are inline in the hvm_domain and hvm_vcpu structures respectively. Subsequent patches will need to add sizable extra fields to the viridian structures which will cause the PAGE_SIZE limit of the overall vcpu structure to be exceeded. This

[Xen-devel] [PATCH v3 9/9] viridian: add implementation of the HvSendSyntheticClusterIpi hypercall

This patch adds an implementation of the hypercall as documented in the specification [1], section 10.5.2. This enlightenment, as with others, is advertised by CPUID leaf 0x4004 and is under control of a new 'hcall_ipi' option in libxl. If used, this enlightenment should mean the guest only

Re: [Xen-devel] [PATCH v5 09/15] argo: implement the sendv op; evtchn: expose send_guest_global_virq

>>> On 31.01.19 at 11:18, wrote: > On Wed, Jan 30, 2019 at 08:10:28PM -0800, Christopher Clark wrote: >> On Tue, Jan 22, 2019 at 4:08 AM Roger Pau Monné wrote: >> > On Mon, Jan 21, 2019 at 01:59:49AM -0800, Christopher Clark wrote: >> > > +/* >> > > + * Check padding is zeroed.

Re: [Xen-devel] [PATCH v5 04/15] argo: init, destroy and soft-reset, with enable command line opt

>>> On 31.01.19 at 05:06, wrote: > On Mon, Jan 21, 2019 at 9:55 AM Roger Pau Monné wrote: >> On Mon, Jan 21, 2019 at 01:59:44AM -0800, Christopher Clark wrote: >> > +static void >> > +pending_remove_all(const struct domain *d, struct argo_ring_info >> > *ring_info) >> > +{ >> > +struct

  1   2   >