From: Oleksandr Andrushchenko
If frontend is configured to expose multiple connectors then backend may
require a way to uniquely identify concrete virtual connector within the
frontend. This is useful for use-cases where connector needs to be
matched to physical display connector.
Add XenBus "uni
From: Oleksandr Andrushchenko
In current kbdif protocol definition multi-touch device parameters
are described as a part of frontend's XenBus configuration nodes while
they belong to backend's configuration. Fix this by moving
the parameters to the proper section.
Fixes: b7a3ce49d528 ("xen/kbdif
From: Oleksandr Andrushchenko
If frontend is configured to expose multiple input device instances
then backend may require a way to uniquely identify concrete input
device within the frontend. This is useful for use-cases where
virtual input device needs to be matched to physical input device.
Ad
On 05/23/2018 07:00 AM, Takashi Sakamoto wrote:
Hi,
On May 14 2018 15:27, Oleksandr Andrushchenko wrote:
> diff --git a/sound/xen/xen_snd_front_alsa.c
b/sound/xen/xen_snd_front_alsa.c
> new file mode 100644
> index ..5041f83e98d2
> --- /dev/null
> +++ b/sound/xen/xen_snd_front_alsa
On 22/05/18 18:45, Ian Jackson wrote:
> Signed-off-by: Ian Jackson
Acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 22/05/18 18:45, Ian Jackson wrote:
> The 4.10 release preparation was significantly more hairy than ideal.
> (We seem to have a good overall outcome despite, rather than because
> of, our approach.)
>
> This is the second time (at least) that we have come close to failure
> by committing to a r
On 22/05/18 19:46, Julien Grall wrote:
> I forgot to CC Juergen as RM. This series is candidate for Xen 4.11 as
> part of XSA-263.
For XSA patches I don't think you need it, but you can have my
Release-acked-by: Juergen Gross
for the series, of course.
Juergen
___
On 22/05/18 21:47, Marek Marczykowski-Górecki wrote:
> Older gcc does not support #pragma GCC diagnostics, so use alternative
> approach - change variable type to uint32_t (this code handle 32-bit
> requests only anyway), which apparently also avoid gcc complaining about
> this (otherwise correct)
Hi,
On May 14 2018 15:27, Oleksandr Andrushchenko wrote:
> diff --git a/sound/xen/xen_snd_front_alsa.c
b/sound/xen/xen_snd_front_alsa.c
> new file mode 100644
> index ..5041f83e98d2
> --- /dev/null
> +++ b/sound/xen/xen_snd_front_alsa.c
> ...
> +/*
> + * FIXME: The mmaped data trans
flight 122987 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122987/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken in 122915
Tests
On Thu, May 17, 2018 at 7:52 AM, George Dunlap wrote:
> On 05/15/2018 07:06 PM, Dan Williams wrote:
>> On Tue, May 15, 2018 at 7:19 AM, George Dunlap
>> wrote:
>>> So, who decides what this SPA range and interleave set is? Can the
>>> operating system change these interleave sets and mappings,
HAS_GICV3 has become selectable by the user. To mark the change, rename
the option from HAS_GICV3 to GICV3.
Suggested-by: Julien Grall
Signed-off-by: Stefano Stabellini
---
Changes in v3:
- no changes
Changes in v2:
- patch added
---
xen/arch/arm/Kconfig | 4 ++--
xen/arch/arm/Makefile
Have arm and x86 select HAS_MEM_ACCESS to mark that they can do
MEM_ACCESS.
Select an additional MEM_ACCESS_ALWAYS_ON on x86 to mark that MEM_ACCESS
is not configurable on x86.
Rename HAS_MEM_ACCESS to MEM_ACCESS everywhere else. Add a prompt and a
description to MEM_ACCESS in xen/common/Kconfig.
Hi all,
This patch series is the first step toward building a small certifiable
Xen hypervisor for ARM boards.
First, the series makes a few changes to allow disabling more kconfig
options: most of them already exist but cannot be disabled.
Then, it introduces a reference kconfig for Renesas RCa
Add a Xen build target to count the lines of code of the source files
built. Uses `cloc' to do the job.
With Xen on ARM taking off in embedded, IoT, and automotive, we are
seeing more and more uses of Xen in constrained environments. Users and
system integrators want the smallest Xen and Dom0 conf
UART drivers are now selectable by the user. To mark the change, remove
the HAS_ prefix.
Use HAS_* options to mark which options are available on which
architecture. Use HAS_*_ALWAYS_ON options to mark which options are
silent and always enabled on a given architecture.
Make NS16550 and EHCI sile
Today it is a silent option. This patch adds a one line description and
makes it optional.
Signed-off-by: Stefano Stabellini
---
Changes in v3:
- remove any changes to MEM_ACCESS
- update commit message
Changes in v2:
- make HAS_GICv3 depend on ARM_64
- remove modifications to ARM_HDLCD kconfig
The ARM HDLCD driver is unused. The device itself can only be found on
Virtual Express boards that are for early development only. Remove the
driver.
Also remove vexpress_syscfg, now unused, and "select VIDEO" that is not
useful anymore.
Suggested-by: Julien Grall
Signed-off-by: Stefano Stabelli
Add a tiny kconfig configuration. Enabled NULL and Credit schedulers.
Support only 4 cpus. It only carries non-default options (use make
olddefconfig to produce a complete .config file).
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/configs/tiny.conf | 44 +++
All the UART drivers are silent options. Add one line descriptions so
that can be de/selected via menuconfig.
Signed-off-by: Stefano Stabellini
CC: jbeul...@suse.com
CC: andrew.coop...@citrix.com
---
The next patch will take care of fixing arch dependencies.
Changes in v3:
- NS16550 prompt if AR
Introduce a Kconfig option for the ARM SMMUv1 and SMMUv2 driver.
Signed-off-by: Stefano Stabellini
CC: jbeul...@suse.com
---
Changes in v3:
- rename SMMUv2 to ARM_SMMU
- improve help message
- use if ARM
Changes in v2:
- rename HAS_SMMUv2 to SMMUv2
- move SMMUv2 to xen/drivers/passthrough/Kconf
Add a "Platform Support" menu with three umbrella kconfig options: QEMU,
RCAR3 and MPSOC. They enable the required options for their hardware
platform.
They are introduced for convience: the user will be able to simply open
the menu and enable the right config for her platform.
Signed-off-by: Ste
On Tue, 22 May 2018, Julien Grall wrote:
> Hi,
>
> On 22/05/2018 22:00, Stefano Stabellini wrote:
> > On Tue, 22 May 2018, Julien Grall wrote:
> > > Hi,
> > >
> > > On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
> > > > This is a reference tiny kconfig for Renesas RCar. In terms of
> > > > sc
On Tue, 22 May 2018, Jan Beulich wrote:
> >>> Stefano Stabellini 05/22/18 2:53 AM >>>
> >UART drivers are now selectable by the user. To mark the change, remove
> >the HAS_ prefix.
>
> Same comment as on patch 3.
I'll do. That will also solve your comments to the previous patch in a
cleaner way.
George Dunlap:
> On Fri, May 18, 2018 at 5:19 PM, Marek Marczykowski
> wrote:
>> On Fri, May 18, 2018 at 09:54:37AM -0600, Jan Beulich wrote:
>> On 18.05.18 at 17:33, wrote:
Yes, I'm happy to help with that. As I've said, the basic test is very
simple (rtcwake command) and already v
On Tue, 22 May 2018, Jan Beulich wrote:
> >>> Stefano Stabellini 05/22/18 2:53 AM >>>
> >HAS_MEM_ACCESS has become selectable by the user on ARM32 and ARM64. To
> >mark the change, rename the option from HAS_MEM_ACCESS to MEM_ACCESS.
>
> I have a different suggestion, a model used (iirc) in a cou
Hi,
On 22/05/2018 22:00, Stefano Stabellini wrote:
On Tue, 22 May 2018, Julien Grall wrote:
Hi,
On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
This is a reference tiny kconfig for Renesas RCar. In terms of
schedulers, it selects credit and NULL only. It enables all the ARM64
errata.
It
On Tue, 22 May 2018, Julien Grall wrote:
> Hi,
>
> On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
> > This is a reference tiny kconfig for Renesas RCar. In terms of
> > schedulers, it selects credit and NULL only. It enables all the ARM64
> > errata.
>
> It still does not feel right that you
flight 122982 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122982/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 12 guest-start fail REGR. vs. 118324
test-armhf-armhf-li
On Tue, 22 May 2018, Julien Grall wrote:
> On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
> > Make it possible to disable the following existing kconfig options:
> >HAS_GICV3
> >HAS_MEM_ACCESS
> >
> > Today they are silent option. This patch adds one line descriptions and
> > make them
On Tue, 22 May 2018, Julien Grall wrote:
> Hi,
>
> On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
> > Make it possible to disable the following existing kconfig options:
> >HAS_GICV3
> >HAS_MEM_ACCESS
> >
> > Today they are silent option. This patch adds one line descriptions and
> > m
On Tue, 22 May 2018, Julien Grall wrote:
> Hi,
>
> On 05/21/2018 08:58 PM, Stefano Stabellini wrote:
> > On Thu, 19 Apr 2018, Julien Grall wrote:
> > > > +
> > > > +config HAS_MEM_ACCESS
> > > > + bool
> > > > + prompt "Memory Access and VM events"
> > > > + default y
> > >
> >
Hi Jan
On Tue, May 22, 2018 at 03:26:06AM -0600, Jan Beulich wrote:
> >>> On 22.05.18 at 10:59, wrote:
> > Do you think it is acceptable that we just follow linux kernel at present
> > and work out optimizations later?
>
> In the worst case I could live with it, but I'd be far from happy if so.
On Tue, 22 May 2018, Jan Beulich wrote:
> >>> On 22.05.18 at 02:53, wrote:
> > --- a/xen/Makefile
> > +++ b/xen/Makefile
> > @@ -267,3 +267,14 @@ $(KCONFIG_CONFIG):
> > include/config/auto.conf.cmd: ;
> >
> > -include $(BASEDIR)/include/config/auto.conf.cmd
> > +
> > +.PHONY: cloc
> > +cloc: b
On Tue, 22 May 2018, Jan Beulich wrote:
> >--- a/xen/drivers/passthrough/Kconfig
> >+++ b/xen/drivers/passthrough/Kconfig
> >@@ -1,3 +1,11 @@
> >
> >config HAS_PASSTHROUGH
> >bool
> >+
> >+config SMMUv2
> >+bool "ARM SMMUv1 and v2 driver"
> >+default y
> >+depends on ARM
>
> Anticipat
On Tue, 22 May 2018, Julien Grall wrote:
> Hi,
>
> On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
> > Introduce a Kconfig option for the ARM SMMUv1 and SMMUv2 driver.
> >
> > Signed-off-by: Stefano Stabellini
> > CC: jbeul...@suse.com
> >
> > ---
> > Changes in v2:
> > - rename HAS_SMMUv2 to
On Tue, 22 May 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 05/22/2018 01:53 AM, Stefano Stabellini wrote:
> > The ARM HDLCD driver is unused. The device itself can only be found on
> > Virtual Express boards that are for early development only. Remove the
> > driver.
> >
> > Suggested-by: Juli
Older gcc does not support #pragma GCC diagnostics, so use alternative
approach - change variable type to uint32_t (this code handle 32-bit
requests only anyway), which apparently also avoid gcc complaining about
this (otherwise correct) code.
Fixes 437e00fea04becc91c1b6bc1c0baa636b067a5cc "tools/
On Tue, May 22, 2018 at 11:54:36AM +0100, Wei Liu wrote:
> I have tried to revert 437e00fea04becc91c1b6bc1c0baa636b067a5cc and
> reproduce the gcc 8.1 warning with Arch Linux's gcc 8.1 compiler.
> Strangely it doesn't complain.
>
> I haven't got a Fedora 28 around (which Marek used). It will take
On Tue, 22 May 2018, Jan Beulich wrote:
> >>> Stefano Stabellini 05/22/18 2:53 AM >>>
> >All the UART drivers are silent options. Add one line descriptions so
> >that can be de/selected via menuconfig.
> >
> >Signed-off-by: Stefano Stabellini
>
> Please don't forget to Cc maintainers.
You and A
On Tue, May 22, 2018 at 6:24 AM, Jan Beulich wrote:
On 21.05.18 at 18:59, wrote:
>> After closer inspection the problem is with the following line here:
>>
for ( i = 1; i < argc; ++i )
>>
>> This assumes that argv[0] is the EFI executable filename, which is not
>> true when EFI
On 05/22/2018 11:00 AM, Oleksandr Andrushchenko wrote:
> On 05/22/2018 05:33 PM, Boris Ostrovsky wrote:
>> On 05/22/2018 01:55 AM, Oleksandr Andrushchenko wrote:
>>> On 05/21/2018 11:36 PM, Boris Ostrovsky wrote:
On 05/21/2018 03:13 PM, Oleksandr Andrushchenko wrote:
> On 05/21/2018 09:53
On 05/22/2018 02:27 PM, Oleksandr Andrushchenko wrote:
> On 05/22/2018 09:02 PM, Boris Ostrovsky wrote:
>> On 05/22/2018 11:00 AM, Oleksandr Andrushchenko wrote:
>>> On 05/22/2018 05:33 PM, Boris Ostrovsky wrote:
On 05/22/2018 01:55 AM, Oleksandr Andrushchenko wrote:
> On 05/21/2018 11:36
From: Paul Durrant
This patch adds grant table helper functions to the xen_backend code to
localize error reporting and use of xen_domid.
The patch also defers the call to xengnttab_open() until just before the
initialise method in XenDevOps is invoked. This method is responsible for
mapping the
From: Paul Durrant
All the xen stable APIs define handle types of the form:
xen_handle
and some define additional handle types of the form:
xen__handle
Examples of these are xenforeignmemory_handle and
xenforeignmemory_resource_handle.
Both of these types will be misparsed by checkpatch if t
From: Paul Durrant
The code is sufficiently substantial that it improves code readability
to put it in a new function called by xen_hvm_init() rather than having
it inline.
Signed-off-by: Paul Durrant
Reviewed-by: Anthony Perard
Signed-off-by: Stefano Stabellini
---
hw/i386/xen/xen-hvm.c | 7
From: Paul Durrant
Currently the xen_disk source has to carry #ifdef exclusions to compile
against Xen older then 4.8. This is a bit messy so this patch lifts the
definition of struct xengnttab_grant_copy_segment and adds it into the
pre-4.8 compat area in xen_common.h, which allows xen_disk to b
From: Igor Druzhinin
This should help to avoid problems with accessing the device after
migration/resume without PV drivers by migrating its PCI configuration
space state. Without an explicitly defined state record it resets
every time a VM migrates which confuses the OS and makes every
access to
From: Anthony PERARD
Signed-off-by: Anthony PERARD
Reviewed-by: Markus Armbruster
Signed-off-by: Stefano Stabellini
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 59f91ab..a8498ab 100755
--- a/configure
+++ b/configure
@@ -1588,7
From: Paul Durrant
Now that helpers are present in xen_backend, this patch removes open-coded
calls to libxengnttab from the xen_disk code.
This patch also fixes one whitspace error in the assignment of the
XenDevOps initialise method.
Signed-off-by: Paul Durrant
Acked-by: Anthony Perard
Sign
From: Paul Durrant
Now that helpers are available in xen_backend, use them throughout all
Xen PV backends.
Signed-off-by: Paul Durrant
Acked-by: Anthony Perard
Signed-off-by: Stefano Stabellini
---
hw/9pfs/xen-9p-backend.c | 32 +++-
hw/char/xen_console.c| 9
From: Paul Durrant
Certain functions in xen_disk are called with a pointer to xendev
(struct XenDevice *). They then use container_of() to acces the surrounding
blkdev (struct XenBlkDev) but then in various places use &blkdev->xendev
when use of the original xendev pointer is shorter to express a
From: Paul Durrant
Since xen_disk now always copies data to and from a guest there is no need
to maintain a vector entry corresponding to every page of a request.
This means there is less per-request state to maintain so the ioreq
structure can shrink significantly.
Signed-off-by: Paul Durrant
From: Igor Druzhinin
Commit 99605175c (xen-pt: Fix PCI devices re-attach failed) introduced
a subtle bug. As soon as the guest switches off Bus Mastering on the
device it immediately causes all the BARs be unmapped due to the DMA
address space of the device being changed. This is undesired behavi
From: Paul Durrant
Now that the (native or emulated) xen_be_copy_grant_refs() helper is
always available, the xen_disk code can be significantly simplified by
removing direct use of grant map and unmap operations.
Signed-off-by: Paul Durrant
Acked-by: Anthony Perard
Signed-off-by: Stefano Stab
ttp/people/sstabellini/qemu-dm.git
tags/xen-20180522-tag
for you to fetch changes up to 443c3c9cf1a18afcc705745d18101a4ea4de5b26:
xen_disk: be consistent with use of xendev and blkdev->xendev (2018-05-22
11:43:22 -0700)
X
From: Paul Durrant
There is no longer any use of this flag outside of the xen_backend code.
Signed-off-by: Paul Durrant
Acked-by: Anthony Perard
Signed-off-by: Stefano Stabellini
---
hw/xen/xen_backend.c | 2 +-
include/hw/xen/xen_backend.h | 1 -
2 files changed, 1 insertion(+), 2 d
From: Paul Durrant
Not all Xen environments support the xengnttab_grant_copy() operation.
E.g. where the OS is FreeBSD or Xen is older than 4.8.0.
This patch introduces an emulation of that operation using
xengnttab_map_domain_grant_refs() and memcpy() for those environments.
Signed-off-by: Pau
From: Ross Lagerwall
The full size of the BAR is stored in the lower PCIIORegion.size. The
upper PCIIORegion.size is 0. Calculate the size of the upper half
correctly from the lower half otherwise the size read by the guest will
be incorrect.
Signed-off-by: Ross Lagerwall
Acked-by: Anthony PER
On Mon 21-05-18 23:20:21, Huaisheng Ye wrote:
> From: Huaisheng Ye
>
> Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with encoded zone number.
>
> Delete ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 from GFP bitmasks,
> the bottom three bits of GFP mask is reserved for storing encoded
> zone number.
>
On Tue, 22 May 2018, Peter Maydell wrote:
> On 21 May 2018 at 20:34, Stefano Stabellini wrote:
> > The following changes since commit d32e41a1188e929cc0fb16829ce3736046951e39:
> >
> > Merge remote-tracking branch
> > 'remotes/famz/tags/docker-and-block-pull-request' into staging (2018-05-18
>
On 05/22/2018 09:02 PM, Boris Ostrovsky wrote:
On 05/22/2018 11:00 AM, Oleksandr Andrushchenko wrote:
On 05/22/2018 05:33 PM, Boris Ostrovsky wrote:
On 05/22/2018 01:55 AM, Oleksandr Andrushchenko wrote:
On 05/21/2018 11:36 PM, Boris Ostrovsky wrote:
On 05/21/2018 03:13 PM, Oleksandr Andrushc
On Tue, 22 May 2018, Jarvis Roach wrote:
> > > For instance, here is another idea: we could have Xen boot multiple
> > > domains at boot time from device tree, as suggested in the dom0-less
> > > approach. All of the domains booted from Xen are "mission-critical".
> > > The first domain could still
I forgot to CC Juergen as RM. This series is candidate for Xen 4.11 as
part of XSA-263.
Cheers,
On 22/05/18 18:42, Julien Grall wrote:
Hi all,
This patch series implement the Xen hypervisor side of the "Spectre-v4"
(CVE-2018-3639) mitigation known as "Speculative Store Bypass Disable"
(SSBD).
Using current is fairly expensive, so save up into a variable.
Signed-off-by: Julien Grall
---
xen/arch/arm/traps.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 020b0b8eef..b1546f6907 100644
--- a/xen/arch/ar
On a system where the firmware implements ARCH_WORKAROUND_2, it may be
useful to either permanently enable or disable the workaround for cases
where the user decides that they'd rather not get a trap overhead, and
keep the mitigation permanently on or off instead of switching it on
exception entry/
In order to offer ARCH_WORKAROUND_2 support to guests, we need to track the
state of the workaround per-vCPU. The field 'pad' in cpu_info is now
repurposed to store flags easily accessible in assembly.
As the hypervisor will always run with the workaround enabled, we may
need to enable (on guest e
The function ARM_SMCCC_ARCH_WORKAROUND_2 will be called by the guest for
enabling/disabling the ssbd mitigation. So we want the handling to
be as fast as possible.
The new sequence will forward guest's ARCH_WORKAROUND_2 call to EL3 and
also track the state of the workaround per-vCPU.
Note that si
This is part of XSA-263.
Signed-off-by: Julien Grall
---
I am aware of the missing commit message here. I wanted to send the
series on the ML to get some feedback first.
---
xen/arch/arm/alternative.c | 35 +--
1 file changed, 13 insertions(+), 22 deletio
This is based on the Linux commit dea5e2a4c5bc "arm64: alternatives: Add
dynamic patching feature" written by Marc Zyngier:
We've so far relied on a patching infrastructure that only gave us
a single alternative, without any way to provide a range of potential
replacement instructions.
Add assembly macros to simplify assembly code:
- adr_cpu_info: Get the address to the current cpu_info structure
- ldr_this_cpu: Load a per-cpu value
This is part of XSA-263.
Signed-off-by: Julien Grall
---
xen/include/asm-arm/arm64/macros.h | 25 +
xen/include/a
Some errata will rely on the SMCCC version which is detected by
psci_init().
This is part of XSA-263.
Signed-off-by: Julien Grall
---
xen/arch/arm/setup.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 1d6f6bf37e..ac
As for Spectre variant-2, we rely on SMCCC 1.1 to provide the discovery
mechanism for detecting the SSBD mitigation.
A new capability is also allocated for that purpose, and a config
option.
This is part of XSA-263.
Signed-off-by: Julien Grall
---
xen/arch/arm/Kconfig | 10
Signed-off-by: Julien Grall
---
xen/include/asm-arm/smccc.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index a6804cec99..74c13f8419 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@
Hi all,
This patch series implement the Xen hypervisor side of the "Spectre-v4"
(CVE-2018-3639) mitigation known as "Speculative Store Bypass Disable"
(SSBD).
More information can be found at:
https://bugs.chromium.org/p/project-zero/issues/detail?id=1528
https://developer.arm.com/support/ar
At the moment, HARDEN_BRANCH_PREDICTOR is not in any section making
impossible for the user to unselect it.
Also, it looks like we require to use 'expert = "y"' for showing the
option in expert mode.
Signed-off-by: Julien Grall
---
xen/arch/arm/Kconfig | 34 +-
1
A stack is allocated per vCPU to be used by Xen. The allocation is done
with alloc_xenheap_pages that does not zero the memory returned. However
the top of the stack is containing information that will be used to
store the initial state of the vCPU (see struct cpu_info). Some of the
fields may not
This will improve readability for future changes.
This is part of XSA-263.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm64/entry.S | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
index ffa9a1c492..e2344e565f
flight 122977 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122977/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 122357
test-amd64-i386-l
On 05/22/2018 12:32 PM, Jan Beulich wrote:
On 22.05.18 at 18:20, wrote:
>> On 05/22/2018 12:10 PM, Jan Beulich wrote:
>> On 22.05.18 at 17:15, wrote:
On Tue, May 22, 2018 at 9:57 AM, Jan Beulich wrote:
On 22.05.18 at 15:45, wrote:
>> On Mon, May 21, 2018 at 11:54 PM,
flight 123071 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123071/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
From: Ian Jackson
This is my third attempt to get consensus for this. We had a
discussion about this in December and again in April.
Technically I think the fact that I have Juergen's ack on the
controversial patch ought to be sufficient, since he is the RM, but I
would prefer to proceed with c
Signed-off-by: Ian Jackson
---
docs/process/RUBRIC | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 docs/process/RUBRIC
diff --git a/docs/process/RUBRIC b/docs/process/RUBRIC
new file mode 100644
index 000..78aca80
--- /dev/null
+++ b/docs/process/RUBRIC
@@ -0,0 +1,
The 4.10 release preparation was significantly more hairy than ideal.
(We seem to have a good overall outcome despite, rather than because
of, our approach.)
This is the second time (at least) that we have come close to failure
by committing to a release date before the exact code to be released
i
>>> On 22.05.18 at 18:20, wrote:
> On 05/22/2018 12:10 PM, Jan Beulich wrote:
> On 22.05.18 at 17:15, wrote:
>>> On Tue, May 22, 2018 at 9:57 AM, Jan Beulich wrote:
>>> On 22.05.18 at 15:45, wrote:
> On Mon, May 21, 2018 at 11:54 PM, Boris Ostrovsky
>
> wrote:
>> @@ -98,6
On 05/22/2018 12:10 PM, Jan Beulich wrote:
On 22.05.18 at 17:15, wrote:
>> On Tue, May 22, 2018 at 9:57 AM, Jan Beulich wrote:
>> On 22.05.18 at 15:45, wrote:
On Mon, May 21, 2018 at 11:54 PM, Boris Ostrovsky
wrote:
> @@ -98,6 +101,12 @@ ENTRY(pvh_start_xen)
>
On 05/22/2018 05:05 PM, Jan Beulich wrote:
On 22.05.18 at 17:46, wrote:
>>> Btw, so far you've only mentioned XPTI and BTI collectively enabled or
>>> disabled. Have you tried with one of them on and the other off?
>>
>> Just tried it. bti=off crashes. xpti=off works.
>
> "works" as in pro
>>> On 22.05.18 at 17:15, wrote:
> On Tue, May 22, 2018 at 9:57 AM, Jan Beulich wrote:
> On 22.05.18 at 15:45, wrote:
>>> On Mon, May 21, 2018 at 11:54 PM, Boris Ostrovsky
>>> wrote:
@@ -98,6 +101,12 @@ ENTRY(pvh_start_xen)
/* 64-bit entry point. */
.code64
>
Ian Jackson writes ("Re: [PATCH] tools: prepend to PKG_CONFIG_PATH when
configuring qemu"):
> Juergen Gross writes ("Re: [PATCH] tools: prepend to PKG_CONFIG_PATH when
> configuring qemu"):
> > On 26/04/18 19:41, Stewart Hildebrand wrote:
> > > A user may choose to set his/her own PKG_CONFIG_PATH
>>> On 22.05.18 at 17:52, wrote:
> On Fri, May 18, 2018 at 12:40 PM, Jan Beulich wrote:
>> this should go out in a week or two. Please point out backport candidates you
>> find missing from its staging branch, but which you consider relevant.
>
> XPTI speed-ups?
I don't have backports of them f
>>> On 22.05.18 at 17:46, wrote:
>> Btw, so far you've only mentioned XPTI and BTI collectively enabled or
>> disabled. Have you tried with one of them on and the other off?
>
> Just tried it. bti=off crashes. xpti=off works.
"works" as in produces a register dump, I assume?
Jan
__
>>> On 22.05.18 at 17:25, wrote:
> With your code dump patch (sorry for the wrapping):
>
> (XEN) *** DOUBLE FAULT ***
> (XEN) [ Xen-4.11-rc x86_64 debug=y Not tainted ]
> (XEN) CPU:0
> (XEN) RIP:e008:[] handle_exception+0x9c/0xff
> (XEN) RFLAGS: 00010006 CONTEXT: hyp
On Fri, May 18, 2018 at 12:40 PM, Jan Beulich wrote:
> All,
>
> this should go out in a week or two. Please point out backport candidates you
> find missing from its staging branch, but which you consider relevant.
XPTI speed-ups?
-George
___
Xen-dev
On 05/22/2018 04:32 PM, Jan Beulich wrote:
On 22.05.18 at 16:50, wrote:
>> In fact, with `s3_fake` enabled, Xen just hangs when XPTI / BTI are
>> enabled; but with it disabled, I actually get a stack trace. Serial
>> output and xen-syms.map attached.
>
> Interesting (not sure if I simply di
No functional change.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v3:
- Rebase on top of Jan's MTRR fixes.
Changes since v2:
- Use unsigned int instead of uint8_t in mtrr_pat_not_equal.
---
xen/arch/x86/cpu/mtrr/main.c
And enable MTRR. This allows to provide a sane initial MTRR state for
PVH DomUs. This will have to be expanded when pci-passthrough support
is added to PVH guests, so that MMIO regions of devices are set as
UC.
Note that initial MTRR setup is done by hvmloader for HVM guests,
that's not used by PV
From: Jan Beulich
The code hopefully is more readable this way.
Also switch have_fixed to bool, seeing that it already is used as a
boolean.
Signed-off-by: Jan Beulich
[switched to use MASK_*]
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/cpu/mtrr/ge
Expand the size of the variable ranges array to match the size of the
underlying hardware, this is a preparatory change for copying the
hardware MTRR state for Dom0.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v2:
- Use Dom%u in hvm_vcpu_cacheattr_ini
From: Jan Beulich
We should not assume that the incoming set of values contains exactly
MTRR_VCNT variable range MSRs. Permit a smaller amount and reject a
bigger one. As a result the save path then also needs to no longer use
a fixed upper bound, in turn requiring unused space in the save record
Copy the state found on the hardware when creating a PVH Dom0. Since
the memory map provided to a PVH Dom0 is based on the native one using
the same set of MTRR ranges should provide Dom0 with a sane MTRR state
without having to manually build it in Xen.
Signed-off-by: Roger Pau Monné
---
Cc: Jan
1 - 100 of 204 matches
Mail list logo
