> From: Paul Durrant [mailto:pdurr...@amazon.com]
> Sent: Wednesday, November 20, 2019 8:09 PM
>
> This patch introduces a new iommu_op to facilitate a per-implementation
> quarantine set up, and then further code for x86 implementations
> (amd and vtd) to set up a read/wrote scratch page to serve
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, November 22, 2019 6:16 AM
>
> The VT-x task switch handler adds inst_len to rip before calling
> hvm_task_switch(). This causes early faults to be delivered to the guest
> with
> trap semantics, and break restartibility.
>
On 23.11.19 05:29, Elliott Mitchell wrote:
On Thu, Nov 21, 2019 at 04:46:21PM +0100, J??rgen Gro?? wrote:
On 21.11.19 16:36, Jan Beulich wrote:
On 21.11.2019 15:24, J??rgen Gro?? wrote:
So: no, just giving dom0 access to the management hardware isn't going
to fly. You need to have a proper vir
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
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 install
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 page
Translated domains shouldn't see host physical addresses. While the
address is also not supposed to be handed back even to non-translated
domains when GNTMAP_device_map is not set (as explicitly stated by a
comment in the public header), PV kernels (Linux at least) assume the
field to get populated
On 23.11.2019 00:10, Andreas Kinzler wrote:
> BTW: Xeon E-2136 @ C242 has 8086:3eca as ID. One needs to check with
> Intel which combinations are really affected.
Are you saying you observed the same issue on such a (server processor)
system as well? Neither its datasheet nor its specification up
flight 144288 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144288/
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
Hi All,
I am trying vsnd from xen-troops with xen 4.13 and Linux 5.4, but domu reports:
aplay compl.mp3
ALSA lib
../../../alsa-lib-1.1.9/src/pcm/pcm_direct.c:1156:(snd1_pcm_direct_initialize_slave)
slave plugin does not support mmap interleaved or mmap noninterleaved access
ALSA lib ../../../als
On 25/11/2019 10:19, Peng Fan wrote:
Hi All,
Hi,
I am trying vsnd from xen-troops with xen 4.13 and Linux 5.4, but domu reports:
xen-troops is not part of Xen Project. Please contact the owner of the
repo for any help here.
I have CCed Artem who should be able to point to the author o
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 25 November 2019 09:58
> To: xen-devel@lists.xenproject.org
> Cc: Juergen Gross ; Stefano Stabellini
> ; Julien Grall ; Wei Liu
> ; Konrad Wilk ; George Dunlap
> ; Andrew Cooper ;
> Sander Eikelenboom ; Ian Jackson
>
Hello Peng Fan
Please contact Oleksandr Andrushchenko (added to this thread) on this
issue.
-- Artem
On Mon, 2019-11-25 at 10:24 +, Julien Grall wrote:
>
> On 25/11/2019 10:19, Peng Fan wrote:
> > Hi All,
>
> Hi,
>
> > I am trying vsnd from xen-troops with xen 4.13 and Linux 5.4, but
> >
On 23.11.2019 19:00, Doug Goldstein wrote:
> Per README, GCC 4.1.2 should lead to a successful default "make install"
> per INSTALL. Currently this is failing due to tools/tests/x86_emulator
> being in the default path and requiring a compiler with AVX. GCC 4.4.7
> on CentOS 6 does not have this
On 25.11.2019 11:37, Durrant, Paul wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 25 November 2019 09:58
>>
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -4304,9 +4304,17 @@ static int hvmop_set_param(
>> if ( a.value
> -Original Message-
> From: Jan Beulich
> Sent: 25 November 2019 10:51
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Ian Jackson ; Roger
> Pau Monné ; Sander Eikelenboom
> ; George Dunlap ;
> Stefano Stabellini ; Konrad Wilk
> ; Juergen Gross ; Julien Grall
On 11/25/19 12:40 PM, Artem Mygaiev wrote:
Hello Peng Fan
Please contact Oleksandr Andrushchenko (added to this thread) on this
issue.
-- Artem
On Mon, 2019-11-25 at 10:24 +, Julien Grall wrote:
On 25/11/2019 10:19, Peng Fan wrote:
Hi All,
Hi,
I am trying vsnd from xen-troops with x
On Fri, Nov 22, 2019 at 06:08:13PM +, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] [PATCH v2 1/3] libxl: introduce new backend
> type VINPUT"):
> > On Fri, Nov 22, 2019 at 04:43:03PM +0100, Jürgen Groß wrote:
> > > Release-acked-by: Juergen Gross
> >
> > I take it this applies to bo
The core device API performs extra housekeeping bits that are missing
from directly calling cpu_up/down.
See commit a6717c01ddc2 ("powerpc/rtas: use device model APIs and
serialization during LPM") for an example description of what might go
wrong.
This also prepares to make cpu_up/down a private
Changes in v2:
* Add 2 new patches that create smp_shutdown_nonboot_cpus() to be used
in machine_shutdown() in ia64, arm and arm64
* Use proper kernel-doc for the newly introduced functions
* Renamed a function
* Removed a stale comment in a function
flight 144290 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144290/
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.
144233
Tests which did not
> Cc: sstabell...@kernel.org; jul...@xen.org; xen-de...@lists.xen.org
> Subject: Re: [Xen-devel] vsnd issue
>
> On 11/25/19 12:40 PM, Artem Mygaiev wrote:
> > Hello Peng Fan
> >
> > Please contact Oleksandr Andrushchenko (added to this thread) on this
> > issue.
> >
> > -- Artem
> >
> > On Mon,
Hi all,
Xen 4.13 rc3 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.13.0-rc3
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.13.0-rc3/xen-4.13.0-rc3.tar.gz
And the signature is at:
https://downloads.xenproject.org
Hi all,
Xen 4.13 rc3 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.13.0-rc3
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.13.0-rc3/xen-4.13.0-rc3.tar.gz
And the signature is at:
https://downloads.xenproject.org
Changeset ca2eee92df44 ("x86, hvm: Expose host core/HT topology to HVM
guests") attempted to "fake up" a topology which would induce guest
operating systems to not treat vcpus as sibling hyperthreads. This
involved actually reporting hyperthreading as available, but giving
vcpus every other ApicId
On 25.11.19 13:39, George Dunlap wrote:
Changeset ca2eee92df44 ("x86, hvm: Expose host core/HT topology to HVM
guests") attempted to "fake up" a topology which would induce guest
operating systems to not treat vcpus as sibling hyperthreads. This
involved actually reporting hyperthreading as avai
On 25.11.2019 11:15, Jan Beulich wrote:
On 23.11.2019 00:10, Andreas Kinzler wrote:
BTW: Xeon E-2136 @ C242 has 8086:3eca as ID. One needs to check with
Intel which combinations are really affected.
Are you saying you observed the same issue on such a (server processor)
system as well? Neither
On 25.11.2019 13:39, George Dunlap wrote:
> Changeset ca2eee92df44 ("x86, hvm: Expose host core/HT topology to HVM
> guests") attempted to "fake up" a topology which would induce guest
> operating systems to not treat vcpus as sibling hyperthreads. This
> involved actually reporting hyperthreading
On Mon, Nov 25, 2019 at 12:39:23PM +, George Dunlap wrote:
> Changeset ca2eee92df44 ("x86, hvm: Expose host core/HT topology to HVM
> guests") attempted to "fake up" a topology which would induce guest
> operating systems to not treat vcpus as sibling hyperthreads. This
> involved actually rep
flight 144294 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144294/
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
On 25.11.2019 03:22, Chao Gao wrote:
> On Fri, Nov 22, 2019 at 04:47:23PM +, Sergey Dyasli wrote:
>> Currently if a user tries to live-load the same or older ucode revision
>> than CPU already has, he will get a single message in Xen log like:
>>
>>(XEN) 128 cores are to update their microc
On Mon, Nov 25, 2019 at 2:25 PM Peng Fan wrote:
>
> > Cc: sstabell...@kernel.org; jul...@xen.org; xen-de...@lists.xen.org
> > Subject: Re: [Xen-devel] vsnd issue
> >
> > On 11/25/19 12:40 PM, Artem Mygaiev wrote:
> > > Hello Peng Fan
> > >
> > > Please contact Oleksandr Andrushchenko (added to thi
On 11/25/19 3:31 PM, Oleksandr Grytsov wrote:
On Mon, Nov 25, 2019 at 2:25 PM Peng Fan wrote:
Cc: sstabell...@kernel.org; jul...@xen.org; xen-de...@lists.xen.org
Subject: Re: [Xen-devel] vsnd issue
On 11/25/19 12:40 PM, Artem Mygaiev wrote:
Hello Peng Fan
Please contact Oleksandr Andrushchen
There are two mappings active in the middle of do_recalc(), and hence
commit 0d0f4d78e5d1 ("p2m: change write_p2m_entry to return an error
code") should have added (or otherwise invoked) unmapping code just
like it did in p2m_next_level(), despite us not expecting any errors
here. Arrange for the e
On 11/25/19 4:44 AM, Jan Beulich wrote:
On 23.11.2019 19:00, Doug Goldstein wrote:
Per README, GCC 4.1.2 should lead to a successful default "make install"
per INSTALL. Currently this is failing due to tools/tests/x86_emulator
being in the default path and requiring a compiler with AVX. GCC 4.4
flight 144289 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144289/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-rtds 17 guest-saverestore.2 fail in 144283 pass in 144289
test-amd64-amd64-libvirt-xsm 7
On 11/21/19 12:05 AM, Jürgen Groß wrote:
Where do we stand with Xen 4.13 regarding blockers and related patches?
1. Currently the default "make install" fails with errors in
tools/tests/x86_emulator if you don't have a new enough GCC. Causing
failures on distros that are considered still supp
On 9/16/19 12:30 PM, Pawel Wieczorkiewicz wrote:
> This change is part of a independant stacked hotpatch modules
> feature. This feature allows to bypass dependencies between modules
> upon loading, but still verifies Xen build ID matching.
>
> With stacked hotpatch modules it is essential that ea
On 25.11.2019 14:58, osstest service owner wrote:
> flight 144289 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/144289/
>
> Failures :-/ but no regressions.
>
> Tests which are failing intermittently (not blocking):
> test-amd64-amd64-xl-rtds 17 guest-saverestore.2
Hello,
The following build failure happens when using clang to build the hypervisor.
This is a default config.
make -f /builds/xen-project/xen/xen/Rules.mk
/builds/xen-project/xen/xen/.xen.efi.0r.o
/builds/xen-project/xen/xen/.xen.efi.0s.o
grep -v 'DEFINE_XEN_GUEST_HANDLE(long)' public/nmi.h
Cc Roger -- you're our resident Clang expert. :-)
On Mon, Nov 25, 2019 at 08:02:17AM -0600, Doug Goldstein wrote:
> On 11/21/19 12:05 AM, Jürgen Groß wrote:
>
> > Where do we stand with Xen 4.13 regarding blockers and related patches?
> >
> 1. Currently the default "make install" fails with erro
On 25.11.2019 15:02, Doug Goldstein wrote:
> 2. The hypervisor currently fails to build with clang using versions
> that READM says are supported no matter the configuration.
Did you post any details of this anywhere?
Jan
___
Xen-devel mailing list
Xe
On 9/16/19 12:30 PM, Pawel Wieczorkiewicz wrote:
> Include new sections containing optional apply and revert action
> hooks.
>
> The following new section names are supported:
> - .livepatch.hooks.apply
> - .livepatch.hooks.revert
>
> Signed-off-by: Pawel Wieczorkiewicz
Reviewed-by: Ross Lag
On 25.11.2019 14:52, Doug Goldstein wrote:
> On 11/25/19 4:44 AM, Jan Beulich wrote:
>
>> On 23.11.2019 19:00, Doug Goldstein wrote:
>>> Per README, GCC 4.1.2 should lead to a successful default "make install"
>>> per INSTALL. Currently this is failing due to tools/tests/x86_emulator
>>> being in
On 9/16/19 12:30 PM, Pawel Wieczorkiewicz wrote:
> With version 2 of a payload structure additional field is supported
> to track whether given function has been applied or reverted.
> There also comes additional 8-byte alignment padding to reserve
> place for future flags and options.
>
> The new
L.S.,
At present one of my PVH VM's kernel crashed with the splat below
(haven't seen it before, so could be something that happens sporadically).
Any ideas ?
--
Sander
database databaselogin: login: [184503.428811] general protection fault:
[#1] SMP NOPTI
[184503.428887] CPU: 0 PID: 0
On 9/16/19 12:30 PM, Pawel Wieczorkiewicz wrote:
> Extend livepatch_patch_func to support a new field: expect. This new
> field describes the expected data, its length and whether expectation
> is enabled. The expectation's data is of opaque padding size.
>
> By default the expectation field is ze
On 25.11.2019 15:06, Doug Goldstein wrote:
> Hello,
>
> The following build failure happens when using clang to build the hypervisor.
> This is a default config.
>
> make -f /builds/xen-project/xen/xen/Rules.mk
> /builds/xen-project/xen/xen/.xen.efi.0r.o
> /builds/xen-project/xen/xen/.xen.efi.
On 9/16/19 12:30 PM, Pawel Wieczorkiewicz wrote:
> In the process of creating a final hotpatch module file make sure to
> strip all transient symbols that have not been caught and removed by
> create-diff-object processing. For now these are only the hooks
> kpatch load/unload symbols.
>
> For all
On 11/25/19 1:49 PM, Jan Beulich wrote:
> There are two mappings active in the middle of do_recalc(), and hence
> commit 0d0f4d78e5d1 ("p2m: change write_p2m_entry to return an error
> code") should have added (or otherwise invoked) unmapping code just
> like it did in p2m_next_level(), despite us
On 25.11.2019 15:21, Sander Eikelenboom wrote:
> L.S.,
>
> At present one of my PVH VM's kernel crashed with the splat below
> (haven't seen it before, so could be something that happens sporadically).
>
> Any ideas ?
>
> --
> Sander
>
>
>
> database databaselogin: login: [184503.428811] gen
Jürgen Groß writes ("Re: [Xen-devel] [OSSTEST PATCH 00/13] Speed up and restore
host history"):
> On 20.11.19 18:54, Ian Jackson wrote:
> > Hi, I promised you to do a risk/benefit analysis on this series and
> > here is my report. With your permission I plan to push it on Sunday
> > night or Mond
Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 144289: tolerable
FAIL"):
> On 25.11.2019 14:58, osstest service owner wrote:
...
> > test-amd64-amd64-libvirt-xsm 7 xen-boot fail pass in
> > 144283
>
> Other than the shell prompt not appearing, I can't see any
> indi
This hypercall can take a long time to finish because it attempts to
grab the `hostp2m' lock up to 1024 times. The accumulated wait for the
lock can take several seconds.
This can easily happen with a guest with 32 vcpus and plenty of RAM,
during localhost migration.
Signed-off-by: Anthony PERARD
(+ Andre)
On 23/11/2019 20:35, Julien Grall wrote:
Hi,
On 15/11/2019 20:10, Stewart Hildebrand wrote:
Allow vgic_get_hw_irq_desc to be called with a vcpu argument.
Use vcpu argument in vgic_connect_hw_irq.
vgic_connect_hw_irq is called for PPIs and SPIs, not SGIs. Enforce with
ASSERTs.
Sign
On 25/11/2019 15:42, Jan Beulich wrote:
> On 25.11.2019 15:21, Sander Eikelenboom wrote:
>> L.S.,
>>
>> At present one of my PVH VM's kernel crashed with the splat below
>> (haven't seen it before, so could be something that happens sporadically).
>>
>> Any ideas ?
>>
>> --
>> Sander
>>
>>
>>
>> da
flight 144292 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144292/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e0f8261ad02217fa8ed57c95c379c2fc8fd67210
baseline version:
ovmf 54a07f8fe088d1fe3b7a6
All,
the 4.12.2 stable release is due in about 2 weeks time. Please point
out backporting candidates that you find missing from the respective
stable trees.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mail
On Mon, Nov 25, 2019 at 1:55 PM Jürgen Groß wrote:
>
> On 23.11.19 05:29, Elliott Mitchell wrote:
> > On Thu, Nov 21, 2019 at 04:46:21PM +0100, J??rgen Gro?? wrote:
> >> On 21.11.19 16:36, Jan Beulich wrote:
> >>> On 21.11.2019 15:24, J??rgen Gro?? wrote:
> So: no, just giving dom0 access to
On 25.11.2019 16:43, Rishi wrote:
> Next is the MSR read for actual temperature values. Currently
> rdmsr_safe_on_cpu is being used, does it already get converted to a
> Hypercall to be able to detect values?
> While tracing the function calls from code, rdmsr_safe_on_cpu() ->
> rdmsr_safe() -> nat
On 14/11/2019 12:28, Igor Druzhinin wrote:
> 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
>
On 14/11/2019 12:28, Igor Druzhinin wrote:
> 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
>>
On Mon, Nov 25, 2019 at 02:06:06PM +, Wei Liu wrote:
> Cc Roger -- you're our resident Clang expert. :-)
>
> On Mon, Nov 25, 2019 at 08:02:17AM -0600, Doug Goldstein wrote:
> > On 11/21/19 12:05 AM, Jürgen Groß wrote:
> >
> > > Where do we stand with Xen 4.13 regarding blockers and related pa
The physical timer traps apply an offset so that time starts at 0 for
the guest. However, this offset is not currently applied to the physical
counter. Per the ARMv8 Arch Reference Manual, the offset between the
physical timer and counter should be 0. This removes the offset to make
the timer and c
On 25.11.2019 15:59, Anthony PERARD wrote:
> This hypercall can take a long time to finish because it attempts to
> grab the `hostp2m' lock up to 1024 times. The accumulated wait for the
> lock can take several seconds.
>
> This can easily happen with a guest with 32 vcpus and plenty of RAM,
> dur
flight 144291 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144291/
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
On 9/16/19 12:30 PM, Pawel Wieczorkiewicz wrote:
> Strip all unneeded metadata symbols from generated hotpatch modules.
> The metadata symbols are the symbols from metadata-like sections (e.g.
> '.livepatch.funcs') or livepatch hooks symbols (defined by a set of
> prefixes. E.g. 'livepatch_load_dat
On 11/5/19 3:37 PM, Pawel Wieczorkiewicz wrote:
> The rela groups in the *.fixup sections vary in size. That makes it
> more complex to handle in the livepatch_strip_undefined_elements().
> It is also unnecessary as the .fixup sections are unlikely to have
> any STN_UNDEF symbols anyway.
>
> Signe
On Mon, Nov 25, 2019 at 04:59:31PM +0100, Roger Pau Monné wrote:
[...]
>
> Which I think it's expected, we already knew clang had a lot of
> duplicate symbols. The only way I know to workaround this ATM is to
> use `gmake xen clang=y CONFIG_ENFORCE_UNIQUE_SYMBOLS=n`. It's on my
> pile of stuff to
On 11/5/19 3:37 PM, Pawel Wieczorkiewicz wrote:
> This is needed for more precise patchability verification.
> Only non-special .rodata sections should be subject
> for such a non-referenced check in kpatch_verify_patchability().
> Current check (non-standard, non-rela, non-debug) is too weak and
>
When using global pages a full tlb flush can only be performed by
toggling the PGE bit in CR4, which is usually quite expensive in terms
of performance when running virtualized. This is specially relevant on
AMD hardware, which doesn't have the ability to do selective CR4
trapping, but can also be
When PCID is not available Xen does a full tlbflush by toggling the
PGE bit in CR4. This is not necessary if PGE is not enabled, since a
flush can be performed by writing to CR3 in that case.
Change the code in do_tlb_flush to only toggle the PGE bit in CR4 if
it's already enabled, otherwise do th
Hello,
Enabling PGE in CR4 causes a huge performance penalty when running the
shim on AMD hardware, this patch series avoids enabling PGE when in
shim mode, and makes a small adjustment in do_tlb_flush to perform a
flush by writing to CR3 if PGE is not enabled.
Roger Pau Monne (2):
x86/tlbflush
On Mon, Nov 25, 2019 at 05:07:04PM +, Wei Liu wrote:
> On Mon, Nov 25, 2019 at 04:59:31PM +0100, Roger Pau Monné wrote:
> [...]
> >
> > Which I think it's expected, we already knew clang had a lot of
> > duplicate symbols. The only way I know to workaround this ATM is to
> > use `gmake xen cla
On 25/11/2019 17:27, Roger Pau Monné wrote:
> On Mon, Nov 25, 2019 at 05:07:04PM +, Wei Liu wrote:
>> On Mon, Nov 25, 2019 at 04:59:31PM +0100, Roger Pau Monné wrote:
>> [...]
>>> Which I think it's expected, we already knew clang had a lot of
>>> duplicate symbols. The only way I know to worka
On Mon, Nov 25, 2019 at 05:22:19PM +0100, Jan Beulich wrote:
> On 25.11.2019 15:59, Anthony PERARD wrote:
> > This hypercall can take a long time to finish because it attempts to
> > grab the `hostp2m' lock up to 1024 times. The accumulated wait for the
> > lock can take several seconds.
> >
> > T
On Mon, Nov 25, 2019 at 05:34:15PM +, Andrew Cooper wrote:
> On 25/11/2019 17:27, Roger Pau Monné wrote:
> > On Mon, Nov 25, 2019 at 05:07:04PM +, Wei Liu wrote:
> >> On Mon, Nov 25, 2019 at 04:59:31PM +0100, Roger Pau Monné wrote:
> >> [...]
> >>> Which I think it's expected, we already kn
On Mon, Nov 25, 2019 at 05:34:15PM +, Andrew Cooper wrote:
> On 25/11/2019 17:27, Roger Pau Monné wrote:
> > On Mon, Nov 25, 2019 at 05:07:04PM +, Wei Liu wrote:
> >> On Mon, Nov 25, 2019 at 04:59:31PM +0100, Roger Pau Monné wrote:
> >> [...]
> >>> Which I think it's expected, we already kn
The tx/rx fifo flags were not set when the vpl011 is initialized. This
is a problem for certain guests that are operating in polled mode, as a
guest will generally check the rx fifo empty flag to determine if there
is data before doing a read. The result is a continuous spam of the
message "vpl011:
On 10/10/19 9:11 AM, Ian Jackson wrote:
> According to git log -G:
>
> 0x040700 was introduced in 304400459ef0 (aka 4.7.0-rc1~481)
>"tools/libxl: rename remus device to checkpoint device"
>
> 0x040800 was introduced in 57f8b13c7240 (aka 4.8.0-rc1~437)
>"libxl: memory size in kb requires 6
Hi,
On 25/11/2019 18:35, Jeff Kubascik wrote:
The tx/rx fifo flags were not set when the vpl011 is initialized. This
is a problem for certain guests that are operating in polled mode, as a
guest will generally check the rx fifo empty flag to determine if there
is data before doing a read. The re
flight 144293 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144293/
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
Hello,
On 11/25/2019 2:20 PM, Julien Grall wrote:
> Hi,
>
> On 25/11/2019 18:35, Jeff Kubascik wrote:
>> The tx/rx fifo flags were not set when the vpl011 is initialized. This
>> is a problem for certain guests that are operating in polled mode, as a
>> guest will generally check the rx fifo empt
The tx/rx fifo flags were not set when the vpl011 is initialized. This
is a problem for certain guests that are operating in polled mode, as a
guest will generally check the rx fifo empty flag to determine if there
is data before doing a read. The result is a continuous spam of the
message "vpl011:
IV bit shouldn't be set in DTE if interrupt remapping is not
enabled. This was traced to be a root cause behind assertion in
interrupt handling code on Lisbon.
Signed-off-by: Igor Druzhinin
---
xen/drivers/passthrough/amd/iommu_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
Hi,
On 15/11/2019 20:10, Stewart Hildebrand wrote:
From: Ian Campbell
Make use of the GICD I[SC]ACTIVER registers to save and
restore the active state of the interrupt.
For edge triggered interrupts we also need to context switch the
pending bit via I[SC]PENDR. Note that for level triggered i
(+ Andre)
Hi,
On 15/11/2019 20:14, Stewart Hildebrand wrote:
From: Ian Campbell
... instead of artificially masking the timer interrupt in the timer
state and relying on the guest to unmask (which it isn't required to
do per the h/w spec, although Linux does).
By using the newly added hwppi
Hi,
On 25/11/2019 16:14, Jeff Kubascik wrote:
The physical timer traps apply an offset so that time starts at 0 for
the guest. However, this offset is not currently applied to the physical
counter. Per the ARMv8 Arch Reference Manual, the offset between the
Which bit of the Arm Arm do you refe
Hi,
On 25/11/2019 20:58, Jeff Kubascik wrote:
The tx/rx fifo flags were not set when the vpl011 is initialized. This
is a problem for certain guests that are operating in polled mode, as a
guest will generally check the rx fifo empty flag to determine if there
is data before doing a read. The re
On Mon, 25 Nov 2019, Julien Grall wrote:
> (+ Andre)
>
> On 23/11/2019 20:35, Julien Grall wrote:
> > Hi,
> >
> > On 15/11/2019 20:10, Stewart Hildebrand wrote:
> > > Allow vgic_get_hw_irq_desc to be called with a vcpu argument.
> > >
> > > Use vcpu argument in vgic_connect_hw_irq.
> > >
> > >
The pull request you sent on Mon, 25 Nov 2019 06:34:54 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.5a-rc1-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3f3c8be973af10875cfa1e7b85a535b6ba76b44f
Thank you!
--
Deet-doot-dot, I
flight 144295 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144295/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs.
144289
Tests which
On Sun, Nov 24, 2019 at 4:48 PM Marek Marczykowski-Górecki
wrote:
>
> On Fri, Nov 22, 2019 at 10:00:13PM -0800, Roman Shaposhnik wrote:
> > 3. Bad news: Marek's suggestion didn't work on Dell product line (and yes
> > I double checked that I built it correctly).
> >
> > So... when it comes to RC2
On Mon, Nov 25, 2019 at 07:44:03PM -0800, Roman Shaposhnik wrote:
> On Sun, Nov 24, 2019 at 4:48 PM Marek Marczykowski-Górecki
> wrote:
> > Do you have by
> > a chance messages of that crash (without efi=no-rs, but with
> > EFI_SET_VIRTUAL_ADDRESS_MAP enabled)? Or even a photo if no serial output
flight 144298 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144298/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf bd85bf54c268204c7a698a96f3ccd96cd77952cd
baseline version:
ovmf e0f8261ad02217fa8ed57
flight 144297 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144297/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail REGR. vs. 144250
Tests which did not succee
On Mon, Nov 25, 2019 at 7:55 PM Marek Marczykowski-Górecki
wrote:
>
> On Mon, Nov 25, 2019 at 07:44:03PM -0800, Roman Shaposhnik wrote:
> > On Sun, Nov 24, 2019 at 4:48 PM Marek Marczykowski-Górecki
> > wrote:
> > > Do you have by
> > > a chance messages of that crash (without efi=no-rs, but with
97 matches
Mail list logo
