flight 167703 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167703/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
flight 167700 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167700/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 167697
test-armhf-armhf-libvirt 16 sav
On Thu, 2022-01-13 at 12:05 +, Anthony PERARD wrote:
> On Wed, Jan 12, 2022 at 05:41:36PM +0100, Dario Faggioli wrote:
>
> > 2) there should be nothing to free anyway
>
> The issue here is that it doesn't appear to be true. Even if "info"
> is
> NULL, "nr" have an other value than 0, so libxl
On Fri, 14 Jan 2022, Dario Faggioli wrote:
> On Thu, 2022-01-06 at 17:52 -0800, Stefano Stabellini wrote:
> > On Thu, 6 Jan 2022, Julien Grall wrote:
> > >
> > > This issue and solution were discussed numerous time on the ML. In
> > > short, we
> > > want to tell the RCU that CPU running in guest
flight 167698 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167698/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64 8 xen-bootfail REGR. vs. 167684
test-amd64-amd64-xl
flight 167697 qemu-mainline real [real]
flight 167699 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167697/
http://logs.test-lab.xenproject.org/osstest/logs/167699/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-ar
On Thu, 2022-01-06 at 17:52 -0800, Stefano Stabellini wrote:
> On Thu, 6 Jan 2022, Julien Grall wrote:
> >
> > This issue and solution were discussed numerous time on the ML. In
> > short, we
> > want to tell the RCU that CPU running in guest context are always
> > quiesced.
> > For more details,
I am no longer an employee at AIS. Use my personal email address
instead.
Signed-off-by: Nick Rosbrook
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4a2884dfa7..feea7d14cf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -302,7 +
> > > Currently no IOMMU properties are exposed to dom0, thus kernel by
> > default
> > > assumes no protection and enables swiotlb-xen, which leads to costly
> > > and unnecessary buffers bouncing.
> > >
> > > To let kernel know which device is behing IOMMU and hence needs no
> [Jiamei Xie]
> behi
On 14/01/2022 14:14, Andrew Cooper wrote:
> On 13/01/2022 16:38, Andrew Cooper wrote:
>> The logic was based on a mistaken understanding of how NMI blocking on vmexit
>> works. NMIs are only blocked for EXIT_REASON_NMI, and not for general exits.
>> Therefore, an NMI can in general hit early in th
On Thu, Jan 13, 2022 at 1:48 PM Andrew Cooper wrote:
>
> There is absolutely no need for a function pointer call here.
>
> Drop the hook, introduce a singlestep_supported boolean, and configure it in
> start_vmx() like all other optional functionality.
>
> No functional change, but rather more eff
On Thu, Jan 13, 2022 at 12:02 PM Jan Beulich wrote:
>
> The aim being to have as few indirect calls as possible (see [1]),
> whereas during initial conversion performance was the main aspect and
> hence rarely used hooks didn't get converted. Apparently one use of
> get_interrupt_shadow() was miss
flight 167695 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167695/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-dom0pvh-xl-intel 20 guest-localmigrate/x10 fail pass in 167692
test-amd64-amd64-xl-qemuu-debia
On 13/01/2022 16:38, Andrew Cooper wrote:
> The logic was based on a mistaken understanding of how NMI blocking on vmexit
> works. NMIs are only blocked for EXIT_REASON_NMI, and not for general exits.
> Therefore, an NMI can in general hit early in the vmx_asm_vmexit_handler path,
> and the guest'
On 14/01/2022 13:43, Roger Pau Monné wrote:
> On Fri, Jan 14, 2022 at 01:08:43PM +, Andrew Cooper wrote:
>> On 14/01/2022 12:50, Roger Pau Monné wrote:
>>> On Thu, Jan 13, 2022 at 04:38:33PM +, Andrew Cooper wrote:
The logic was based on a mistaken understanding of how NMI blocking on
On Fri, Jan 14, 2022 at 01:08:43PM +, Andrew Cooper wrote:
> On 14/01/2022 12:50, Roger Pau Monné wrote:
> > On Thu, Jan 13, 2022 at 04:38:33PM +, Andrew Cooper wrote:
> >> The logic was based on a mistaken understanding of how NMI blocking on
> >> vmexit
> >> works. NMIs are only blocked
On Wed, 12 Jan 2022 at 17:14, Stefan Hajnoczi wrote:
>
> The following changes since commit 91f5f7a5df1fda8c34677a7c49ee8a4bb5b56a36:
>
> Merge remote-tracking branch
> 'remotes/lvivier-gitlab/tags/linux-user-for-7.0-pull-request' into staging
> (2022-01-12 11:51:47 +)
>
> are available in
On 14/01/2022 12:50, Roger Pau Monné wrote:
> On Thu, Jan 13, 2022 at 04:38:33PM +, Andrew Cooper wrote:
>> The logic was based on a mistaken understanding of how NMI blocking on vmexit
>> works. NMIs are only blocked for EXIT_REASON_NMI, and not for general exits.
>> Therefore, an NMI can in
On Thu, Jan 13, 2022 at 04:38:33PM +, Andrew Cooper wrote:
> The logic was based on a mistaken understanding of how NMI blocking on vmexit
> works. NMIs are only blocked for EXIT_REASON_NMI, and not for general exits.
> Therefore, an NMI can in general hit early in the vmx_asm_vmexit_handler p
Dongjiu Geng 于2022年1月13日周四 11:47写道：
>
> Hi, Stefano
> Thanks for this reply.
>
> Stefano Stabellini 于2022年1月13日周四 09:52写道：
> >
> > On Wed, 12 Jan 2022, Dongjiu Geng wrote:
> > > > > diff --git a/xen/arch/arm/platforms/Kconfig
> > > > > b/xen/arch/arm/platforms/Kconfig
> > > > > index c93a6b2
flight 167693 linux-linus real [real]
flight 167696 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167693/
http://logs.test-lab.xenproject.org/osstest/logs/167696/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
On 14/01/2022 11:42, Roger Pau Monné wrote:
> On Thu, Jan 13, 2022 at 04:38:32PM +, Andrew Cooper wrote:
>> These were written before Spectre/Meltdown went public, and there was large
>> uncertainty in how the protections would evolve. As it turns out, they're
>> very specific to Intel hardwar
On Thu, Jan 13, 2022 at 04:38:32PM +, Andrew Cooper wrote:
> These were written before Spectre/Meltdown went public, and there was large
> uncertainty in how the protections would evolve. As it turns out, they're
> very specific to Intel hardware, and not very suitable for AMD.
>
> Expand and
On Thu, Jan 13, 2022 at 04:38:31PM +, Andrew Cooper wrote:
> In order to fix a VT-x bug, and support MSR_SPEC_CTRL on AMD, there will need
> to be three different access methods for where the guest's value lives.
> However, it would be better not to duplicate the #GP checking logic.
>
> guest_
On 14/01/2022 07:08, Jan Beulich wrote:
On 07.01.2022 13:55, David Vrabel wrote:
Amazon's guest transparent live migration work needs another save
record (for event channel upcall vectors). Reserve another HVM context
save record ID for this.
I have to admit that I have reservations: I didn
SMBIOS tables like 7,8,9,26,27,28 are neccessary to prevent sandbox detection
by malware
using WMI-queries. New tables can be mapped to memory from binary file
specified in
"smbios_firmware" parameter of domain configuration. If particular table is
absent
in binary file, then it will not be mapp
> -Original Message-
> From: Xen-devel On Behalf Of
> Rahul Singh
> Sent: 2022年1月14日 16:22
> To: Sergiy Kibrik
> Cc: xen-devel ; Stefano Stabellini
> ; Julien Grall ; Oleksandr
> Tyshchenko ; Andrii Anisov
>
> Subject: Re: [XEN PATCH v3] xen/arm: introduce dummy iommu node for
> dom0
flight 167694 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167694/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777
build-arm64-libvirt
Hi,
> On 11 Jan 2022, at 11:26 am, Sergiy Kibrik wrote:
>
> Currently no IOMMU properties are exposed to dom0, thus kernel by default
> assumes no protection and enables swiotlb-xen, which leads to costly and
> unnecessary buffers bouncing.
>
> To let kernel know which device is behing IOMMU an
29 matches
Mail list logo
