On 15.11.19 03:39, Roman Shaposhnik wrote:
* Software: Xen 4.13 RC2
* Hardware: Dell IoT Gateway 3000 series
* Software: Project EVE
* Guest operating systems: Alpine Linux
* Functionality tested: compiling, installing, Booting with dom0=pv
* Comments: All works, aside from xl create often
libxl__dm_resume() is using a wrong timeout for the start of the
device model. Instead of 60 seconds the timeout is set to 60
milliseconds.
Reported-by: Roman Shaposhnik
Fixes: 6298f0eb8f4437 ("libxl: Re-introduce libxl__domain_resume")
Signed-off-by: Juergen Gross
---
branch xen-4.11-testing
xenbranch xen-4.11-testing
job test-amd64-amd64-qemuu-nested-intel
testid debian-hvm-install/l1/l2
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree:
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Friday, November 8, 2019 9:34 PM
>
> When using posted interrupts and the guest migrates MSI from vCPUs Xen
> needs to flush any pending PIRR vectors on the previous vCPU, or else
> those vectors could get wrongly injected at a later
> -Original Message-
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: Friday, November 8, 2019 6:20 PM
> To: Tian, Kevin
> Cc: Joe Jin ; Jan Beulich ;
> Andrew Cooper ; xen-
> de...@lists.xenproject.org; Juergen Gross ; Wei Liu
>
> Subject: Re: [Xen-devel] [PATCH v2]
flight 144120 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144120/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail like 144070
* Software: Xen 4.13 RC2
* Hardware: Dell IoT Gateway 3000 series
* Software: Project EVE
* Guest operating systems: Alpine Linux
* Functionality tested: compiling, installing, Booting with dom0=pv
* Comments: All works, aside from xl create often timing out
The timeout happens when either doing
flight 144109 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144109/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144035
Tests
Hi,
At 23:55 -0500 on 13 Nov (1573689341), Julian Tuminaro wrote:
> From: Julian Tuminaro and Jenish Rakholiya rakholiyajenish...@gmail.com>
>
> Current implementation of find_os is based on the hard-coded values for
> different Windows version. It uses the value for get the address to
> start
flight 144105 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144105/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 144081
test-amd64-amd64-xl-qemuu-ws16-amd64 17
From: Nick Rosbrook
These functions now have a third parameter of type const *libxl_asyncop_how.
Pass nil for this argument to fix compilation and maintain the
synchronous behavior.
Signed-off-by: Nick Rosbrook
---
tools/golang/xenlight/xenlight.go | 4 ++--
1 file changed, 2 insertions(+),
On Thu, Nov 14, 2019 at 11:39 AM Andrew Cooper
wrote:
>
> On 14/11/2019 18:34, Tamas K Lengyel wrote:
> > * Comments: All works, altp2m+introspection requires the ept=pml=0
> > boot flag specified to workaround a deadlock in Xen
>
> Is this separate from the general problem with EPT A/D and
>
flight 144128 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144128/
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 144106 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144106/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf da178f5c5c5832476d37c8a3734815ceea16af86
baseline version:
ovmf
Hello,
I'm working on a port of a RTOS (RTEMS) to Xen on ARM, and came across an
interesting finding in how Xen emulates the physical timer on ARM.
In testing different configurations of the port, I have the RTOS configured to
use the ARM generic physical timer. The driver operates the physical
flight 144099 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144099/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144025
Tests
On 14/11/2019 15:22, Jan Beulich wrote:
> As per SDM rev 071 Cannon Lake has
> - no CC3 residency MSR at 3FC,
> - a CC1 residency MSR ar 660 (like various Atoms),
> - a useless (always zero) CC3 residency MSR at 662.
>
> Signed-off-by: Jan Beulich
> ---
> Using the MSR cross reference in the same
On 14/11/2019 18:34, Tamas K Lengyel wrote:
> * Comments: All works, altp2m+introspection requires the ept=pml=0
> boot flag specified to workaround a deadlock in Xen
Is this separate from the general problem with EPT A/D and
write-protecting pagetables?
~Andrew
* Hardware: i7-2700
* Software: Debian buster
* Guest operating systems: Debian stretch
* Functionality tested: compiling, installing, Booting with dom0=pvh
* Comments: All works
* Hardware: i3-7100
* Software: Debian buster
* Guest operating systems: Debian stretch, debian jessie,
On Thu, Nov 14, 2019 at 04:56:35PM +0100, Jan Beulich wrote:
> On 14.11.2019 14:12, Roger Pau Monné wrote:
> > On Thu, Nov 14, 2019 at 12:43:33PM +0100, Jan Beulich wrote:
> >> On 14.11.2019 10:38, Roger Pau Monné wrote:
> >>> On Wed, Nov 13, 2019 at 06:01:40PM +0100, Jan Beulich wrote:
>
With $(TARGET).efi depending on efi/relocs-dummy.o, arch/x86/Makefile
will attempt to build that object. This result in the dependency file
been generated with relocs-dummy.o depending on efi/relocs-dummy.o.
Then, when arch/x86/efi/Makefile tries to build relocs-dummy.o, well
efi/relocs-dummy.S
On 11/14/19 2:58 PM, Nick Rosbrook wrote:
>> Hmm, this introduces a pretty significant risk of memory leaks; but I
>> don't really see any way around it. I guess we really want to do some
>> SetFinalizer() magic on this to call libxl_cpuid_dispose()?
>>
>> We might also want to add something like
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 14 November 2019 16:42
> To: xen-devel@lists.xenproject.org
> Cc: Juergen Gross ; Sander Eikelenboom
> ; Andrew Cooper
> Subject: [Xen-devel] [PATCH v2 0/2] AMD/IOMMU: re-work mode updating
>
>
On 10/24/19 7:49 PM, Nick Rosbrook wrote:
>> One standard practice when making a series is to try to avoid any
>> regressions, including build regressions, in the middle of the series.
>> This is particularly helpful to aid in bisections, but in this case it
>> makes it easier to observe the
update_paging_mode() expects to be invoked with the PCI devices lock
held. The check occurring only when the mode actually needs updating,
the violation of this rule by the majority of callers did go unnoticed
until per-domain IOMMU setup was changed to do away with on-demand
creation of IOMMU
In order for individual IOMMU drivers (and from an abstract pov also
architectures) to be able to adjust, ahead of actual mapping requests,
their data structures when they might cover only a sub-range of all
possible GFNs, introduce a notification call used by various code paths
potentially
update_paging_mode() in the AMD IOMMU code expects to be invoked with
the PCI devices lock held. The check occurring only when the mode
actually needs updating, the violation of this rule by the majority
of callers did go unnoticed until per-domain IOMMU setup was changed
to do away with on-demand
On 14.11.2019 17:07, Rishi wrote:
> In some of our hosts, Xen is not correctly exposing processor thermal
> capabilities to Dom0.
> Please refer: https://bugzilla.kernel.org/show_bug.cgi?id=205347
>
> The flag
> /* Thermal and Power Management Leaf, CPUID level 0x0006 (EAX), word 14 */
>
On 14.11.2019 17:21, Jan Beulich wrote:
> On 14.11.2019 16:52, osstest service owner wrote:
>> flight 144091 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/144091/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could
On 14/11/2019 16:21, Jan Beulich wrote:
> On 14.11.2019 16:52, osstest service owner wrote:
>> flight 144091 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/144091/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could
On 14.11.2019 16:52, osstest service owner wrote:
> flight 144091 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/144091/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>
> BTW I was discussing with Ian Jackson, and I think at some point it
> would be worth considering adding in an annotation or something to the
> IDL such that the generator can use time.Duration for these things.
> That opens up another can of works, like the fact that Duration is
> int64 rather
Hi,
In some of our hosts, Xen is not correctly exposing processor thermal
capabilities to Dom0.
Please refer: https://bugzilla.kernel.org/show_bug.cgi?id=205347
The flag
/* Thermal and Power Management Leaf, CPUID level 0x0006 (EAX), word 14 */
X86_FEATURE_DTHERM (14*32+ 0)
is returned 0
On 14.11.2019 14:12, Roger Pau Monné wrote:
> On Thu, Nov 14, 2019 at 12:43:33PM +0100, Jan Beulich wrote:
>> On 14.11.2019 10:38, Roger Pau Monné wrote:
>>> On Wed, Nov 13, 2019 at 06:01:40PM +0100, Jan Beulich wrote:
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@
flight 144091 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144091/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12
guest-start/debianhvm.repeat fail REGR.
> So the code you have is probably going to be about equally efficient anyway.
A quick benchmark [1] shows:
goos: linux
goarch: amd64
BenchmarkString1-8500 251 ns/op
BenchmarkString2-8500 247 ns/op
So yes, they're about the same :)
I'll leave it as
On 14.11.2019 15:42, Roger Pau Monné wrote:
> On Thu, Nov 14, 2019 at 02:35:56PM +0100, Jan Beulich wrote:
>> On 13.11.2019 16:59, Roger Pau Monne wrote:
>>> +for ( id = find_first_bit(vcpus, d->max_vcpus);
>>> + id < d->max_vcpus;
>>> + id = find_next_bit(vcpus,
As per SDM rev 071 Cannon Lake has
- no CC3 residency MSR at 3FC,
- a CC1 residency MSR ar 660 (like various Atoms),
- a useless (always zero) CC3 residency MSR at 662.
Signed-off-by: Jan Beulich
---
Using the MSR cross reference in the same SDM revision one might even
get the impression that
On 11/13/19 6:36 PM, Andrew Cooper wrote:
> For system with large numbers of CPUs, the 'r' debugkey is unwieldy. Sibling
> and core masks are a single block of adjacent bits, so are vastly shorter to
> render with %pbl.
>
> Before:
> (XEN) CPU[00] nr_run=0, sort=157,
>
> Hmm, this introduces a pretty significant risk of memory leaks; but I
> don't really see any way around it. I guess we really want to do some
> SetFinalizer() magic on this to call libxl_cpuid_dispose()?
>
> We might also want to add something like a .Dispose() method to have
> predictable
On Thu, Nov 14, 2019 at 02:35:56PM +0100, Jan Beulich wrote:
> On 13.11.2019 16:59, Roger Pau Monne wrote:
> > +for ( id = find_first_bit(vcpus, d->max_vcpus);
> > + id < d->max_vcpus;
> > + id = find_next_bit(vcpus, d->max_vcpus, id + 1) )
> > +{
> > +if (
flight 144097 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144097/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs.
143023
Tests which did
On 10/7/19 4:13 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Add struct and keyed union generation to gengotypes.py. For keyed unions,
> use a method similar to gRPC's oneof to interpret C unions as Go types.
> Meaning, for a given struct with a union field, generate a struct for
> each
On 10/7/19 4:13 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Signed-off-by: Nick Rosbrook
Acked-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hello Julien
On Thu, 2019-11-14 at 08:19 +0900, Julien Grall wrote:
>
>
> On Thu, 14 Nov 2019, 02:15 Artem Mygaiev, <
> artem_myga...@epam.com> wrote:
> > Hi Jan,
> >
> > Sorry for delayed reply
> >
> > On Thu, 2019-11-07 at 08:31 +0100, Jan Beulich wrote:
> > > On 06.11.2019 23:08, Artem
On 13.11.2019 16:59, Roger Pau Monne wrote:
> --- a/xen/arch/x86/hvm/vioapic.c
> +++ b/xen/arch/x86/hvm/vioapic.c
> @@ -212,6 +212,44 @@ static int vioapic_hwdom_map_gsi(unsigned int gsi,
> unsigned int trig,
> return ret;
> }
>
> +static inline int pit_channel0_enabled(void)
> +{
> +
On 13.11.2019 16:59, Roger Pau Monne wrote:
> @@ -5266,6 +5267,36 @@ void hvm_set_segment_register(struct vcpu *v, enum
> x86_segment seg,
> alternative_vcall(hvm_funcs.set_segment_register, v, seg, reg);
> }
>
> +int hvm_intr_get_dests(struct domain *d, uint8_t dest, uint8_t dest_mode,
Hello Julien
On Thu, 2019-11-14 at 08:03 +0900, Julien Grall wrote:
>
>
> On Tue, 12 Nov 2019, 05:57 Stefano Stabellini, <
> sstabell...@kernel.org> wrote:
> > On Wed, 6 Nov 2019, Andrii Anisov wrote:
> > > From: Andrii Anisov
> > >
> > > ARM Compiler 6 has a proven bug: it compiles data only
On Thu, Nov 14, 2019 at 01:25:54PM +0100, Jan Beulich wrote:
> On 13.11.2019 16:59, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > @@ -2054,6 +2054,17 @@ static void vmx_sync_pir_to_irr(struct vcpu *v)
> > unsigned int group, i;
> >
Extend the livepatch list operation to fetch also payloads' metadata.
This is achieved by extending the sysctl list interface with 2 extra
guest handles:
* metadata - an array of arbitrary size strings
* metadata_len - an array of metadata strings' lengths (uin32_t each)
Payloads' metadata is
Having detailed livepatch metadata helps to properly identify module's
origin and version. It also allows to keep track of the history of
livepatch loads in the system (at least within dmesg buffer size
limits).
The livepatch metadata are embedded in a form of .modinfo section.
Each such section
The payloads' name strings can be of arbitrary size (typically small
with an upper bound of XEN_LIVEPATCH_NAME_SIZE).
Current implementation of the list operation interface allows to copy
names in the XEN_LIVEPATCH_NAME_SIZE chunks regardless of its actual
size and enforces space allocation
The payload structure will be used by the new hooks implementation and
therefore its definition has to be exported via the livepatch_payload
header.
The new hooks will make use of the payload structure fields and the
hooks' pointers will also be defined in the payload structure, so
the structure
This is the initial implementation of the expectations enhancement
to improve inline asm livepatching.
Expectations are designed as optional feature, since the main use of
them is planned for inline asm livepatching. The flag enabled allows
to control the expectation state.
Each expectation has
Extend the XC python bindings library to support also all common
livepatch operations and actions.
Add the python bindings for the following operations:
- status (pyxc_livepatch_status):
Requires a payload name as an input.
Returns a status dict containing a state string and a return code
Livepatch only tracks an entire payload applied/reverted state. But,
with an option to supply the apply_payload() and/or revert_payload()
functions as optional hooks, it becomes possible to intermix the
execution of the original apply_payload()/revert_payload() functions
with their dynamically
With default implementation the ELF_LIVEPATCH_FUNC section containing
all functions to be replaced or added must be part of the livepatch
payload, otherwise the payload is rejected (with -EINVAL).
However, with the extended hooks implementation, a livepatch may be
constructed of only hooks to
This is an implementation of 4 new livepatch module vetoing hooks,
that can be optionally supplied along with modules.
Hooks that currently exists in the livepatch mechanism aren't agile
enough and have various limitations:
* run only from within a quiescing zone
* cannot conditionally prevent
By default, in the quiescing zone, a livepatch payload is applied with
apply_payload() and reverted with revert_payload() functions. Both of
the functions receive the payload struct pointer as a parameter. The
functions are also a place where standard 'load' and 'unload' module
hooks are executed.
By default Livepatch enforces the following buildid-based dependency
chain between livepatch modules:
1) first module depends on given hypervisor buildid
2) every consecutive module depends on previous module's buildid
This way proper livepatch stack order is maintained and enforced.
While it
This change is part of a independant stacked livepatch modules
feature. This feature allows to bypass dependencies between modules
upon loading, but still verifies Xen build ID matching.
In order to prevent (up)loading any livepatches built for different
hypervisor version as indicated by the Xen
This series introduces new features to the livepatch functionality as
briefly discussed during Xen Developer Summit 2019: [a] and [b].
It also provides a few fixes and some small improvements.
Main changes in v4:
- Fix various typos and minor issues
- Simplify arch_livepatch_{apply,revert} by
On 11.11.19 15:43, Jan Beulich wrote:
The 1st change is simple cleanup, noticed while preparing for the
2nd patch, which presents the consumer of the interface extension
proposed in
https://lists.xenproject.org/archives/html/xen-devel/2019-11/msg00377.html.
The 3rd patch is sort of optional,
On Thu, Nov 14, 2019 at 06:51:02AM +0100, Jürgen Groß wrote:
> On 14.11.19 00:06, osstest service owner wrote:
> > flight 144067 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/144067/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> >
On 13/11/2019 13:50, Jan Beulich wrote:
> Commit 1b00c16bdf ("AMD/IOMMU: pre-fill all DTEs right after table
> allocation") moved ourselves into a more secure default state, but
> didn't take sufficient care to also undo the effects when handing a
> previously disabled device back to a(nother)
On 11/13/19 9:50 PM, Nick Rosbrook wrote:
>> What's the point of this?
>>
>> I realize it's slightly annoying to have to type `mac[0], mac[1], ...`,
>> but I'd rather do that once than make the runtime copy everything over
>> into a slice of interfaces every String() call.
>
> As I think you
On 13.11.2019 16:59, Roger Pau Monne wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2054,6 +2054,17 @@ static void vmx_sync_pir_to_irr(struct vcpu *v)
> unsigned int group, i;
> DECLARE_BITMAP(pending_intr, NR_VECTORS);
>
> +if ( v != current &&
On 14.11.2019 10:57, Juergen Gross wrote:
> The only way to obtain the current vulnerability settings of Xen is to
> look at the hypervisor boot messages. Often enough the buffer has
> wrapped making it impossible to retrieve that information.
>
> Add a debug key 'b' (like "bugs") for that
On 14.11.2019 10:59, Roger Pau Monne wrote:
> .skip is only used by x86 code, so place the clang .skip with labels
> check in x86/Rules.mk instead of the top level Rules.mk. While there
> also fix an issue with it by removing the '\n' which triggers the
> following error:
>
> :1:31: error:
On 11/11/19 20:55, Andrew Cooper wrote:
"AMD/IOMMU: don't blindly allocate interrupt remapping tables" introduces a
call at runtime from amd_iommu_add_device() to amd_iommu_set_intremap_table()
which is still marked as __init.
On one AMD Rome machine we have, this results in a crash the moment
On 11/13/19 8:53 PM, Nick Rosbrook wrote:
>> Any particular reason to use `cslice` here rather than `mapslice` (or
>> vice versa)?
>>
>> Not a big deal, but since they're of the came element in the C struct,
>> it seems like it would be better to give them the same name. (Don't
>> have a strong
On 14.11.2019 10:38, Roger Pau Monné wrote:
> On Wed, Nov 13, 2019 at 06:01:40PM +0100, Jan Beulich wrote:
>> --- a/xen/arch/x86/Rules.mk
>> +++ b/xen/arch/x86/Rules.mk
>> @@ -82,6 +64,6 @@ $(call as-option-add,CFLAGS,CC,".include
>> # Check whether clang keeps .macro-s between asm()-s:
>> #
On 13.11.19 07:50, Julien Grall wrote:
To be honest, I don't think this file should even exist. This looks like a copy
of xen.lds.S with a different syntax.
And lacking features like symbols definition, current address setup, etc.
Furthermore, the comments from Stefano shows that is going
On 14.11.2019 00:10, Andreas Kinzler wrote:
> I came across the following: https://lkml.org/lkml/2019/8/29/536
>
> Could that be the reason for the problem mentioned below? Xen is using
> HPET as clocksource on the platform/mainboard. Is there an (easy) way to
> verify if Xen uses PC10?
In
On 11.11.19 23:26, Stefano Stabellini wrote:
Why _srodata and __start_bug_frames cannot both be defined as
Load$$_rodata_bug_frames_0$$Base when actually in the case of:
+#define __per_cpu_data_end Load$$_bss_percpu$$Limit
+#define __bss_end
On 14.11.19 11:13, Jan Beulich wrote:
SDM rev 071 points out this fact explicitly.
Signed-off-by: Jan Beulich
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 14/11/2019 10:13, Jan Beulich wrote:
> SDM rev 071 points out this fact explicitly.
>
> Signed-off-by: Jan Beulich
Yes - I found the same note in -071.
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
SDM rev 071 points out this fact explicitly.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4246,10 +4246,12 @@ x86_emulate(
{
/*
* xbegin unconditionally aborts, xabort is
.skip is only used by x86 code, so place the clang .skip with labels
check in x86/Rules.mk instead of the top level Rules.mk. While there
also fix an issue with it by removing the '\n' which triggers the
following error:
:1:31: error: missing terminating '"' character
The only way to obtain the current vulnerability settings of Xen is to
look at the hypervisor boot messages. Often enough the buffer has
wrapped making it impossible to retrieve that information.
Add a debug key 'b' (like "bugs") for that purpose.
Signed-off-by: Juergen Gross
---
This might
On Thu, 14 Nov 2019 at 09:47, Paolo Bonzini wrote:
>
> On 14/11/19 10:39, Paul Durrant wrote:
> > On Wed, 13 Nov 2019 at 14:53, Paolo Bonzini wrote:
> >>
> >> The first machine property to fall is Xen's Intel integrated graphics
> >> passthrough. The "-machine igd-passthru" option does not set
On 14/11/19 10:39, Paul Durrant wrote:
> On Wed, 13 Nov 2019 at 14:53, Paolo Bonzini wrote:
>>
>> The first machine property to fall is Xen's Intel integrated graphics
>> passthrough. The "-machine igd-passthru" option does not set anymore
>> a property on the machine object, but desugars to a
On Wed, 13 Nov 2019 at 14:53, Paolo Bonzini wrote:
>
> The first machine property to fall is Xen's Intel integrated graphics
> passthrough. The "-machine igd-passthru" option does not set anymore
> a property on the machine object, but desugars to a GlobalProperty on
> accelerator objects.
>
>
On Wed, Nov 13, 2019 at 06:01:40PM +0100, Jan Beulich wrote:
> There were two problems here: The first closing parentheses got parsed
> by make to end the $(call invocation, and the escaping of the quotes
> wasn't right either, as there's nowhere they would get un-escaped.
>
> Signed-off-by: Jan
flight 144078 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144078/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144035
Tests
flight 144089 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144089/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c801f33d818b8010fabb93092c661c6f30d42b13
baseline version:
ovmf
> Do you have a call stack trace for this?
(XEN) d0v1: vGICD: unhandled read r1 offset 0x000324
(XEN) traps.c:1994:d0v1 HSR=0x93810006 pc=0x8000104f2bb4
gva=0x800010010324 gpa=0x0051a00324
[1.780564] Unhandled fault at 0x800010010324
[1.785771] Mem abort info:
[
flight 144081 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144081/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 143876
test-amd64-amd64-xl-qemuu-ws16-amd64 17
Hello Stefano,
On 11.11.19 22:59, Stefano Stabellini wrote:
this seems a very serious compiler bug.
Yep.
This, together with the other bug described in the previous patch, makes
me think the ARMCC is not quite ready for showtime.
Yet, this particular ARM Compiler version is safety
Some code is not needed with CONFIG_CRASH_DEBUG, so only include it if
CONFIG_CRASH_DEBUG is defined.
While at it remove CONFIG_HAS_GDBSX as it can easily be replaced by
CONFIG_CRASH_DEBUG.
Signed-off-by: Juergen Gross
---
xen/arch/x86/Kconfig | 1 -
xen/common/Kconfig |
Gdbsx support in the hypervisor is rarely used and it is opening a
way for dom0 to modify the running hypervisor by very easy means.
Add a Kconfig option to control support of gdbsx. Default is off.
While at it correct a wrong comment in related code and remove dead
code.
Signed-off-by: Juergen
Support for debugging the hypervisor of guests via gdb/gdbsx should be
configurable.
Changes in V2:
- split support for gdbstub and gdbsx (Andrew Cooper)
Juergen Gross (2):
xen: put more code under CONFIG_CRASH_DEBUG
xen: make gdbsx support configurable
xen/Kconfig.debug | 7
92 matches
Mail list logo
