On Fri, 1 May 2020, Julien Grall wrote:
> On 01/05/2020 02:26, Stefano Stabellini wrote:
> > On Wed, 15 Apr 2020, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 15/04/2020 02:02, Stefano Stabellini wrote:
> > > > We always use a fix address to map the vPL011 to domains. The address
> > > >
On Fri, 1 May 2020, Julien Grall wrote:
> Hi Stefano,
>
> On 01/05/2020 02:31, Stefano Stabellini wrote:
> > On Wed, 15 Apr 2020, Julien Grall wrote:
> > > > diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> > > > index 4e60ba15cc..4cf430f865 100644
> > > > ---
On Fri, 1 May 2020, Julien Grall wrote:
> On 01/05/2020 02:26, Stefano Stabellini wrote:
> > On Wed, 15 Apr 2020, Julien Grall wrote:
> > > On 15/04/2020 02:02, Stefano Stabellini wrote:
> > > > Today we use native addresses to map the GICv2 for Dom0 and fixed
> > > > addresses for DomUs.
> > > >
On Fri, 1 May 2020, Julien Grall wrote:
> On 01/05/2020 02:26, Stefano Stabellini wrote:
> > On Wed, 15 Apr 2020, Julien Grall wrote:
> > > On 15/04/2020 02:02, Stefano Stabellini wrote:
> > > > In some cases it is desirable to map domU memory 1:1 (guest physical ==
> > > > physical.) For
On Thu, May 7, 2020 at 1:15 AM Jan Beulich wrote:
>
> On 06.05.2020 05:23, Christopher Clark wrote:
> > +It is with this understanding as presented that the DomB project used as
> > the
> > +basis for the development of its multiple domain boot capability for Xen.
> > Within
> > +the remainder
flight 150081 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150081/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150064
test-amd64-amd64-xl-qemut-win7-amd64
Commit a926f81d2f6c ("xen/cpuhotplug: Replace cpu_up/down() with
device_online/offline()") replaced cpu_down() with device_offline()
call which requires that the CPU has been registered before. This
registration, however, happens later from topology_init() which
is called as subsys_initcall().
On 05/05/2020 09:20, Jan Beulich wrote:
> If the hardware can handle accesses, we should allow it to do so. This
> way we can expose EFRO to HVM guests,
I'm reminded now of the conversation I'm sure we've had before, although
I have a feeling it was on IRC.
APERF/MPERF (including the EFRO
flight 150082 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150082/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3a3713e62cfad00d78bb938b0d9fb1eedaeff314
baseline version:
ovmf
On 05/05/2020 09:18, Jan Beulich wrote:
> AMD's PM specifies that MPERF (and its r/o counterpart) reads are
> affected by the TSC ratio. Hence when processing such reads in software
> we too should scale the values. While we don't currently (yet) expose
> the underlying feature flags, besides us
flight 150083 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150083/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
On 05/05/2020 09:16, Jan Beulich wrote:
> Note that FPU selector handling as well as MXCSR mask saving for now
> does not honor differences between host and guest visible featuresets.
>
> While for Intel operation of the insns with CR4.OSFXSR=0 is
> implementation dependent, use the easiest
On 08/05/2020 16:04, Jan Beulich wrote:
>>> +}
>>> +
>>> +if ( bytes == sizeof(fpstate.env) )
>>> +ptr = NULL;
>>> +else
>>> +ptr += sizeof(fpstate.env);
>>> +break;
>>> +
>>> +case sizeof(struct x87_env16):
On 05/05/2020 09:16, Jan Beulich wrote:
> While the Intel SDM claims that FRSTOR itself may raise #MF upon
> completion, this was confirmed by Intel to be a doc error which will be
> corrected in due course; behavior is like FLDENV, and like old hard copy
> manuals describe it. Otherwise we'd have
On 05/05/2020 09:15, Jan Beulich wrote:
> To avoid introducing another boolean into emulator state, the
> rex_prefix field gets (ab)used to convey the real/VM86 vs protected mode
> info (affecting structure layout, albeit not size) to x86_emul_blk().
>
> Signed-off-by: Jan Beulich
> ---
> TBD:
flight 150077 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150077/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 150061
Tests which did
On Fri, May 08, 2020 at 03:46:08PM +0200, Jan Beulich wrote:
> On 07.05.2020 15:22, Roger Pau Monne wrote:
> > diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
> > index b83446e77d..5023fea148 100644
> > --- a/xen/arch/x86/acpi/cpu_idle.c
> > +++
On Fri, May 08, 2020 at 05:04:02PM +0200, Jan Beulich wrote:
> On 08.05.2020 15:37, Roger Pau Monné wrote:
> > On Tue, May 05, 2020 at 10:16:20AM +0200, Jan Beulich wrote:
> >> --- a/tools/tests/x86_emulator/test_x86_emulator.c
> >> +++ b/tools/tests/x86_emulator/test_x86_emulator.c
> >> @@
On Fri, May 08, 2020 at 05:11:35PM +0200, Jan Beulich wrote:
> On 08.05.2020 17:03, Roger Pau Monné wrote:
> > On Fri, May 08, 2020 at 02:43:38PM +0200, Jan Beulich wrote:
> >> --- a/xen/arch/x86/hvm/io.c
> >> +++ b/xen/arch/x86/hvm/io.c
> >> @@ -558,6 +558,47 @@ int
On 08.05.20 17:50, Julien Grall wrote:
On 08/05/2020 15:42, Jürgen Groß wrote:
On 08.05.20 16:23, Tamas K Lengyel wrote:
On Fri, May 8, 2020 at 8:18 AM Jürgen Groß wrote:
On 08.05.20 14:55, Tamas K Lengyel wrote:
On Fri, May 8, 2020 at 6:21 AM Julien Grall wrote:
Hi Jan,
On
On 08/05/2020 15:42, Jürgen Groß wrote:
On 08.05.20 16:23, Tamas K Lengyel wrote:
On Fri, May 8, 2020 at 8:18 AM Jürgen Groß wrote:
On 08.05.20 14:55, Tamas K Lengyel wrote:
On Fri, May 8, 2020 at 6:21 AM Julien Grall wrote:
Hi Jan,
On 08/05/2020 12:20, Jan Beulich wrote:
On
flight 150072 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150072/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 150041
test-amd64-i386-xl-pvshim12
Add support to read and modify values of hypervisor runtime parameters
via the hypervisor file system.
As runtime parameters can be modified via a sysctl, too, this path has
to take the hypfs rw_lock as writer.
For custom runtime parameters the connection between the parameter
value and the file
On the 2019 Xen developer summit there was agreement that the Xen
hypervisor should gain support for a hierarchical name-value store
similar to the Linux kernel's sysfs.
This is a first implementation of that idea adding the basic
functionality to hypervisor and tools side. The interface to any
The functionality of XEN_SYSCTL_set_parameter is available via hypfs
now, so it can be removed.
This allows to remove the kernel_param structure for runtime parameters
by putting the now only used structure element into the hypfs node
structure of the runtime parameters.
Signed-off-by: Juergen
On the 2019 Xen developer summit there was agreement that the Xen
hypervisor should gain support for a hierarchical name-value store
similar to the Linux kernel's sysfs.
In the beginning there should only be basic support: entries can be
added from the hypervisor itself only, there is a simple
Add a new script xen/tools/binfile for including a binary file at build
time being usable via a pointer and a size variable in the hypervisor.
Make use of that generic tool in xsm.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
Reviewed-by: Wei Liu
---
V3:
- new patch
V4:
- add
Add the new library libxenhypfs for access to the hypervisor filesystem.
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
V1:
- rename to libxenhypfs
- add xenhypfs_write()
V3:
- major rework due to new hypervisor interface
- add decompression capability
V4:
- add dependency to libz in
Instead of xc_set_parameters() use xenhypfs_write() for setting
parameters of the hypervisor.
Signed-off-by: Juergen Gross
---
V6:
- new patch
---
tools/Rules.mk | 2 +-
tools/libxl/Makefile | 3 +-
tools/libxl/libxl.c | 53
In case opt_ept_ad has not been set explicitly by the user via command
line or runtime parameter, it is treated as "no" on Avoton cpus.
Change that handling by setting opt_ept_ad to 0 for this cpu type
explicitly if no user value has been set.
By putting this into the (renamed) boot time
Add the infrastructure for the hypervisor filesystem.
This includes the hypercall interface and the base functions for
entry creation, deletion and modification.
In order not to have to repeat the same pattern multiple times in case
adding a new node should BUG_ON() failure, the helpers for
There is no user of xc_set_parameters() left, so remove it.
Signed-off-by: Juergen Gross
---
V6:
- new patch
---
tools/libxc/include/xenctrl.h | 1 -
tools/libxc/xc_misc.c | 21 -
2 files changed, 22 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h
Provide version and compile information in /buildinfo/ node of the
Xen hypervisor file system. As this information is accessible by dom0
only no additional security problem arises.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V3:
- new patch
V4:
- add __read_mostly annotations
Add the /buildinfo/config entry to the hypervisor filesystem. This
entry contains the .config file used to build the hypervisor.
Signed-off-by: Juergen Gross
---
V3:
- store data in gzip format
- use binfile mechanism to create data file
- move code to kernel.c
V6:
- add config item for the
Add the xenfs tool for accessing the hypervisor filesystem.
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
V1:
- rename to xenhypfs
- don't use "--" for subcommands
- add write support
V2:
- escape non-printable characters per default with cat subcommand
(Ian Jackson)
- add -b option to
Tools ping?
~Andrew
On 03/03/2020 18:23, Andrew Cooper wrote:
> xc_cpuid_apply_policy() is gaining extra parameters to untangle CPUID
> complexity in Xen. While an improvement in general, it does have the
> unfortunate side effect of duplicating some settings across muliple
> parameters.
>
>
Allow lowercase a/s/h to be used to annotate a non-default feature.
However, until the toolstack migration logic is fixed, it is not safe to
activate yet. Tolerate the annotations, but ignore them for now.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
CC: Jan Beulich
CC: Wei Liu
On 08.05.2020 17:03, Roger Pau Monné wrote:
> On Fri, May 08, 2020 at 02:43:38PM +0200, Jan Beulich wrote:
>> --- a/xen/arch/x86/hvm/io.c
>> +++ b/xen/arch/x86/hvm/io.c
>> @@ -558,6 +558,47 @@ int register_vpci_mmcfg_handler(struct d
>> return 0;
>> }
>>
>> +int
On 08/05/2020 14:59, Jan Beulich wrote:
> On 08.05.2020 15:00, Andrew Cooper wrote:
>> On 08/05/2020 08:34, Jan Beulich wrote:
> @@ -5660,6 +5661,18 @@ x86_emulate(
> goto done;
> break;
>
> +case 0xe8:
> +switch ( vex.pfx
On 08.05.2020 15:37, Roger Pau Monné wrote:
> On Tue, May 05, 2020 at 10:16:20AM +0200, Jan Beulich wrote:
>> --- a/tools/tests/x86_emulator/test_x86_emulator.c
>> +++ b/tools/tests/x86_emulator/test_x86_emulator.c
>> @@ -2442,6 +2442,27 @@ int main(int argc, char **argv)
>> else
>>
On Fri, May 08, 2020 at 02:43:38PM +0200, Jan Beulich wrote:
> The op has a register/unregister flag, and hence registration shouldn't
> happen unilaterally. Introduce unregister_vpci_mmcfg_handler() to handle
> this case.
>
> Fixes: eb3dd90e4089 ("x86/physdev: enable PHYSDEVOP_pci_mmcfg_reserved
On Fri, May 08, 2020 at 03:49:35PM +0200, Jan Beulich wrote:
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
> unless you have verified the sender and know the content is safe.
>
> On 08.05.2020 14:54, Andrew Cooper wrote:
> > On 08/05/2020 13:43, Jan Beulich wrote:
>
On 08.05.20 16:23, Tamas K Lengyel wrote:
On Fri, May 8, 2020 at 8:18 AM Jürgen Groß wrote:
On 08.05.20 14:55, Tamas K Lengyel wrote:
On Fri, May 8, 2020 at 6:21 AM Julien Grall wrote:
Hi Jan,
On 08/05/2020 12:20, Jan Beulich wrote:
On 08.05.2020 12:00, Julien Grall wrote:
You seem to
On 08.05.2020 15:15, Andrew Cooper wrote:
> On 08/05/2020 08:38, Jan Beulich wrote:
>> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
>> unless you have verified the sender and know the content is safe.
>>
>> On 07.05.2020 22:13, Andrew Cooper wrote:
>>> On 05/05/2020
On Fri, May 8, 2020 at 8:18 AM Jürgen Groß wrote:
>
> On 08.05.20 14:55, Tamas K Lengyel wrote:
> > On Fri, May 8, 2020 at 6:21 AM Julien Grall wrote:
> >>
> >> Hi Jan,
> >>
> >> On 08/05/2020 12:20, Jan Beulich wrote:
> >>> On 08.05.2020 12:00, Julien Grall wrote:
> You seem to be the
On 08.05.20 14:55, Tamas K Lengyel wrote:
On Fri, May 8, 2020 at 6:21 AM Julien Grall wrote:
Hi Jan,
On 08/05/2020 12:20, Jan Beulich wrote:
On 08.05.2020 12:00, Julien Grall wrote:
You seem to be the maintainer with the most unwritten rules. Would
you mind to have a try at writing a
On 08.05.2020 15:00, Andrew Cooper wrote:
> On 08/05/2020 08:34, Jan Beulich wrote:
@@ -5660,6 +5661,18 @@ x86_emulate(
goto done;
break;
+case 0xe8:
+switch ( vex.pfx )
+{
+case
On 08.05.2020 14:54, Andrew Cooper wrote:
> On 08/05/2020 13:43, Jan Beulich wrote:
>> The op has a register/unregister flag, and hence registration shouldn't
>> happen unilaterally. Introduce unregister_vpci_mmcfg_handler() to handle
>> this case.
>>
>> Fixes: eb3dd90e4089 ("x86/physdev: enable
On 07.05.2020 15:22, Roger Pau Monne wrote:
> Apply a workaround for Intel errata CLX30: "A Pending Fixed Interrupt
> May Be Dispatched Before an Interrupt of The Same Priority Completes".
>
> It's not clear which models are affected, as the errata is listed in
> the "Second Generation Intel Xeon
On Tue, May 05, 2020 at 10:16:20AM +0200, Jan Beulich wrote:
> While the Intel SDM claims that FRSTOR itself may raise #MF upon
> completion, this was confirmed by Intel to be a doc error which will be
> corrected in due course; behavior is like FLDENV, and like old hard copy
> manuals describe
On 08/05/2020 08:38, Jan Beulich wrote:
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
> unless you have verified the sender and know the content is safe.
>
> On 07.05.2020 22:13, Andrew Cooper wrote:
>> On 05/05/2020 09:14, Jan Beulich wrote:
>>> ---
On 5/8/20 2:49 PM, Markus Armbruster wrote:
Philippe Mathieu-Daudé writes:
The OBJECT() macro is defined as:
#define OBJECT(obj) ((Object *)(obj))
which expands to:
((Object *)object_dynamic_cast_assert((Object *)(obj), (name),
__FILE__,
On 08/05/2020 08:34, Jan Beulich wrote:
>>> @@ -5660,6 +5661,18 @@ x86_emulate(
>>> goto done;
>>> break;
>>>
>>> +case 0xe8:
>>> +switch ( vex.pfx )
>>> +{
>>> +case vex_none: /* serialize */
>>> +
On Fri, May 8, 2020 at 6:21 AM Julien Grall wrote:
>
> Hi Jan,
>
> On 08/05/2020 12:20, Jan Beulich wrote:
> > On 08.05.2020 12:00, Julien Grall wrote:
> >> You seem to be the maintainer with the most unwritten rules. Would
> >> you mind to have a try at writing a coding style based on it?
> >
>
On 08/05/2020 13:43, Jan Beulich wrote:
> The op has a register/unregister flag, and hence registration shouldn't
> happen unilaterally. Introduce unregister_vpci_mmcfg_handler() to handle
> this case.
>
> Fixes: eb3dd90e4089 ("x86/physdev: enable PHYSDEVOP_pci_mmcfg_reserved for
> PVH Dom0")
>
Philippe Mathieu-Daudé writes:
> The CPU() macro is defined as:
>
> #define CPU(obj) ((CPUState *)(obj))
>
> which expands to:
>
> ((CPUState *)object_dynamic_cast_assert((Object *)(obj), (name),
> __FILE__, __LINE__, __func__))
>
> This assertion
Philippe Mathieu-Daudé writes:
> The OBJECT() macro is defined as:
>
> #define OBJECT(obj) ((Object *)(obj))
>
> which expands to:
>
> ((Object *)object_dynamic_cast_assert((Object *)(obj), (name),
> __FILE__, __LINE__, __func__))
Nope :)
> This
Philippe Mathieu-Daudé writes:
> The DEVICE() macro is defined as:
>
> #define DEVICE(obj) OBJECT_CHECK(DeviceState, (obj), TYPE_DEVICE)
>
> which expands to:
>
> ((DeviceState *)object_dynamic_cast_assert((Object *)(obj), (name),
> __FILE__,
The op has a register/unregister flag, and hence registration shouldn't
happen unilaterally. Introduce unregister_vpci_mmcfg_handler() to handle
this case.
Fixes: eb3dd90e4089 ("x86/physdev: enable PHYSDEVOP_pci_mmcfg_reserved for PVH
Dom0")
Signed-off-by: Jan Beulich
---
Hi Jan,
On 08/05/2020 12:20, Jan Beulich wrote:
On 08.05.2020 12:00, Julien Grall wrote:
You seem to be the maintainer with the most unwritten rules. Would
you mind to have a try at writing a coding style based on it?
On the basis that even small, single aspect patches to CODING_STYLE
have
flight 150088 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150088/
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
flight 150073 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150073/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail REGR. vs. 150042
Tests which did not
On 08.05.2020 12:00, Julien Grall wrote:
> You seem to be the maintainer with the most unwritten rules. Would
> you mind to have a try at writing a coding style based on it?
On the basis that even small, single aspect patches to CODING_STYLE
have been ignored [1], I don't think this would be a
Philippe Mathieu-Daudé wrote:
> This code is not related to hardware emulation.
> Move it under accel/ with the other hypervisors.
>
> Reviewed-by: Paul Durrant
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Juan Quintela
This code is not related to hardware emulation.
Move it under accel/ with the other hypervisors.
Reviewed-by: Paul Durrant
Signed-off-by: Philippe Mathieu-Daudé
---
We could also move the memory management functions from
hw/i386/xen/xen-hvm.c but it is not trivial.
v2: Use
On 08/05/2020 09:36, Jan Beulich wrote:
On 07.05.2020 16:43, Julien Grall wrote:
This was originally discussed during the last community call.
A major part of the comments during review is related to coding style issues.
This can lead to frustration from the contributor as the current
Hi Juan,
On 5/8/20 10:39 AM, Juan Quintela wrote:
Philippe Mathieu-Daudé wrote:
Signed-off-by: Philippe Mathieu-Daudé
---
include/exec/ram_addr.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
index
Philippe Mathieu-Daudé wrote:
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> include/exec/ram_addr.h | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
> index 5e59a3d8d7..dd8713179e 100644
> ---
On 07.05.2020 16:43, Julien Grall wrote:
> This was originally discussed during the last community call.
>
> A major part of the comments during review is related to coding style issues.
> This can lead to frustration from the contributor as the current CODING_STYLE
> is quite light and the
On 08.05.20 10:19, Jan Beulich wrote:
On 07.05.2020 20:36, Dario Faggioli wrote:
On Thu, 2020-04-30 at 17:15 +0200, Juergen Gross wrote:
Commit cb563d7665f2 ("xen/sched: support core scheduling for moving
cpus to/from cpupools") introduced a regression when trying to remove
an offline cpu from
On 07.05.2020 20:36, Dario Faggioli wrote:
> On Thu, 2020-04-30 at 17:15 +0200, Juergen Gross wrote:
>> Commit cb563d7665f2 ("xen/sched: support core scheduling for moving
>> cpus to/from cpupools") introduced a regression when trying to remove
>> an offline cpu from a cpupool, as the system would
On 07.05.2020 20:11, Andrew Cooper wrote:
> On 05/05/2020 09:12, Jan Beulich wrote:
>> In a pure PV environment (the PV shim in particular) we don't really
>> need emulation of all these. To limit #ifdef-ary utilize some of the
>> CASE_*() macros we have, by providing variants expanding to
>>
This code is not related to hardware emulation.
Move it under accel/ with the other hypervisors.
Reviewed-by: Paul Durrant
Signed-off-by: Philippe Mathieu-Daudé
---
We could also move the memory management functions from
hw/i386/xen/xen-hvm.c but it is not trivial.
v2: Use
Signed-off-by: Philippe Mathieu-Daudé
---
include/exec/ram_addr.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
index 5e59a3d8d7..dd8713179e 100644
--- a/include/exec/ram_addr.h
+++ b/include/exec/ram_addr.h
@@
Supersedes: <20200507155813.16169-1-phi...@redhat.com>
Philippe Mathieu-Daudé (2):
exec: Check Xen is enabled before calling the Xen API
accel: Move Xen accelerator code under accel/xen/
include/exec/ram_addr.h| 10 --
include/hw/xen/xen.h | 11
On 07.05.2020 19:26, Andrew Cooper wrote:
> On 05/05/2020 07:31, Jan Beulich wrote:
>> On 21.04.2020 18:40, Roger Pau Monné wrote:
>>> On Tue, Apr 21, 2020 at 11:11:03AM +0200, Jan Beulich wrote:
Drop the NULL checks - they've been introduced by commit 8d7b633ada
("x86/mm: Consolidate
On 07.05.2020 22:13, Andrew Cooper wrote:
> On 05/05/2020 09:14, Jan Beulich wrote:
>> --- a/xen/tools/gen-cpuid.py
>> +++ b/xen/tools/gen-cpuid.py
>> @@ -284,6 +284,9 @@ def crunch_numbers(state):
>> # as dependent features simplifies Xen's logic, and prevents the
>> guest
>> #
On 4/21/20 2:51 PM, Dan Carpenter wrote:
> It turns out there aren't that many of these in xen.
>
> $ grep IS_ERR_OR_NULL drivers/gpu/drm/xen/ -Rn
> drivers/gpu/drm/xen/xen_drm_front_kms.c:63: if (IS_ERR_OR_NULL(fb))
> drivers/gpu/drm/xen/xen_drm_front_gem.c:86: if
On 07.05.2020 21:32, Andrew Cooper wrote:
> On 05/05/2020 09:14, Jan Beulich wrote:
>> ... enabling its use by all guest kinds at the same time.
>>
>> Signed-off-by: Jan Beulich
>
> Acked-by: Andrew Cooper
Thanks.
>> @@ -5660,6 +5661,18 @@ x86_emulate(
>> goto done;
>>
On 07.05.2020 20:59, Andrew Cooper wrote:
> On 05/05/2020 09:13, Jan Beulich wrote:
>> Note that the ISA extensions document revision 038 doesn't specify
>> exception behavior for ModRM.mod == 0b11; assuming #UD here.
>
> Stale.
In which way (beyond the question of whether to use
goto
On 07.05.2020 20:30, Andrew Cooper wrote:
> On 05/05/2020 09:13, Jan Beulich wrote:
>> Introduce a new blk() hook, paralleling the rmw() one in a certain way,
>> but being intended for larger data sizes, and hence its HVM intermediate
>> handling function doesn't fall back to splitting the
On 07.05.2020 22:34, Andrew Cooper wrote:
> On 05/05/2020 09:15, Jan Beulich wrote:
>> In preparation for handling e.g. FLDENV or {F,FX,X}RSTOR here as well.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> v8: New (could be folded into "x86emul: support MOVDIR{I,64B} insns",
>> but would
flight 150070 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150070/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 149905
Regressions which
flight 150068 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150068/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail in 150038 REGR. vs.
149649
Tests
84 matches
Mail list logo
