flight 153740 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153740/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
flight 153738 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153738/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
flight 153736 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153736/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
flight 153737 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153737/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
flight 153735 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153735/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-prev
On Tue, Sep 01, 2020 at 08:01:30AM +0200, Jan Beulich wrote:
> I'm aware, and hence I said "aim for". In cases like this what we
> often do is adjust things incrementally, as lines get touched anyway.
> Of course if you want to clean it up all in one go ...
What I've got has turned into a patch se
On 04.09.20 18:50, Ian Jackson wrote:
Jan Beulich writes ("Re: [xen-unstable test] 153602: regressions - FAIL"):
Actually, with also reverting 8d990807ec2c in the main tree (along with
effectively reverting e013e8514389, which comes down to the same as Ian
suggested for 165f3afbfc3d), and with i
flight 153728 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153728/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl broken
test-armhf-arm
flight 153734 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153734/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
flight 153732 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153732/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
flight 153708 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153708/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 2 hosts-alloca
flight 153688 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153688/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-rtds broken
test-amd64-i386-xl-qemut-stubdom-debianhv
flight 153701 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153701/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-rtds broken
build-i3866 xen-build
On 24/08/2020 13:50, Jan Beulich wrote:
> --- a/xen/include/asm-x86/asm-defns.h
> +++ b/xen/include/asm-x86/asm-defns.h
> @@ -50,3 +50,19 @@
> .macro INDIRECT_JMP arg:req
> INDIRECT_BRANCH jmp \arg
> .endm
> +
> +/*
> + * To guard against speculation past RET, insert a breakpoint insn
> + *
Hello,Can anyone tell me about the goal and features of Mini-OS?
Sent from Yahoo Mail on Android
On Fri, Sep 4, 2020 at 8:31 PM, Ian Jackson wrote:
Currently, xen.git#staging does not build in many environments because
of issues with minios master. This regression was introduced in an
unc
flight 153692 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153692/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 152631
build-amd64
This helps overcome problems observed with some UEFI implementations
which don't set the Attributes field in memery descriptors properly
Signed-off-by: Sergey Temerkhanov
---
xen/common/efi/boot.c| 19 ++-
xen/include/efi/efidef.h | 3 +++
2 files changed, 21 insertions(+),
flight 153727 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153727/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm
On Fri, Sep 4, 2020 at 12:47 PM Jan Beulich wrote:
>
> On 04.09.2020 01:24, Sergey Temerkhanov wrote:
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -1521,7 +1521,9 @@ void __init efi_init_memory(void)
>
> Looking at the line numbers - is this patch against the master
> or
flight 153726 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153726/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm
flight 153720 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153720/
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 Sep 4, 2020, at 11:56 AM, Bertrand Marquis
> wrote:
>
>
>
>> On 4 Sep 2020, at 11:52, George Dunlap wrote:
>>
>>
>>
>>> On Sep 4, 2020, at 11:49 AM, Bertrand Marquis
>>> wrote:
>>>
I tried to add a comment and that is working well
Remarks from my side:
On 04/09/2020 15:40, Jan Beulich wrote:
> On 04.09.2020 13:49, Igor Druzhinin wrote:
>> On 04/09/2020 09:33, Jan Beulich wrote:
>>> On 01.09.2020 04:50, Igor Druzhinin wrote:
Guest kernel does need to know in some cases where the tables are located
to treat these regions properly. One exa
flight 153724 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153724/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm
On Friday, September 4, 2020 2:05 PM, Trammell Hudson wrote:
> On Friday, September 4, 2020 1:58 PM, Julien Grall jul...@xen.org wrote:
> > On 28/08/2020 12:51, Trammell Hudson wrote:
> > > This patch adds support for bundling the xen.efi hypervisor, the xen.cfg
> > > configuration file, the Linu
On Friday, September 4, 2020 1:58 PM, Julien Grall wrote:
> On 28/08/2020 12:51, Trammell Hudson wrote:
> > This patch adds support for bundling the xen.efi hypervisor, the xen.cfg
> > configuration file, the Linux kernel and initrd, as well as the XSM, and
> > CPU microcode into a single "unifie
Hi,
On 28/08/2020 12:51, Trammell Hudson wrote:
This patch adds support for bundling the xen.efi hypervisor, the xen.cfg
configuration file, the Linux kernel and initrd, as well as the XSM, and
CPU microcode into a single "unified" EFI executable.
For Arm, I would also consider to add the DTB
There are multiple bugs with the existing implementation.
On AMD CPUs prior to Zen2, loading a NUL segment selector doesn't clear the
segment base, which is a problem for 64bit code which typically expects to use
a NUL %fs/%gs selector.
On a context switch from any PV vcpu, to a 64bit PV vcpu wit
The comments in save_segments(), _toggle_guest_pt() and write_cr() are false.
The %fs and %gs bases can be updated at any time by the guest.
As a consequence, Xen's fs_base/etc tracking state is always stale when the
vcpu is in context, and must not be used to complete MSR_{FS,GS}_BASE reads,
etc
Split into two patches as more bugs were found with v1.
Andrew Cooper (2):
x86/pv: Fix consistency of 64bit segment bases
x86/pv: Rewrite segment context switching from scratch
xen/arch/x86/domain.c| 199 ---
xen/arch/x86/pv/domain.c
On Fri, Sep 04, 2020 at 10:47:37AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monné
> > Sent: 04 September 2020 09:53
> > To: Paul Durrant
> > Cc: xen-devel@lists.xenproject.org; Paul Durrant ; Ian
> > Jackson
> > ; Wei Liu ; Anthony PERARD
> >
> > Subject: R
flight 153719 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153719/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm
On Fri, Sep 04, 2020 at 05:50:28PM +0100, Ian Jackson wrote:
> Jan Beulich writes ("Re: [xen-unstable test] 153602: regressions - FAIL"):
> > Actually, with also reverting 8d990807ec2c in the main tree (along with
> > effectively reverting e013e8514389, which comes down to the same as Ian
> > sugge
Hi Trammell,
On 04/09/2020 11:06, Trammell Hudson wrote:
On Friday, September 4, 2020 5:29 AM, Julien Grall wrote:
On 28/08/2020 12:51, Trammell Hudson wrote:
- /* PE32+ Subsystem type */
+#if defined(ARM)
Shouldn't this be defined(aarch64) ?
To be honest I'm not sure and don't
> -Original Message-
> From: Jan Beulich
> Sent: 26 August 2020 14:54
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Paul Durrant ;
> Julien Grall ;
> Andrew Cooper ; George Dunlap
> ; Ian Jackson
> ; Stefano Stabellini ; Wei
> Liu ;
> Volodymyr Babchuk ; Roger Pau Monné
>
On Fri, Aug 21, 2020 at 12:34:31PM +0200, David Hildenbrand wrote:
> Let's use the new mechanism to merge system ram resources below the
> root. We are the only one hotplugging system ram, e.g., DIMMs don't apply,
> so this is safe to be used.
>
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: "K. Y
> -Original Message-
> From: Jan Beulich
> Sent: 26 August 2020 14:58
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Paul Durrant ; Ian
> Jackson
> ; Wei Liu ; Andrew Cooper
> ; George
> Dunlap ; Julien Grall ; Stefano
> Stabellini
>
> Subject: Re: [PATCH v7 7/9] common/doma
On Fri, Aug 28, 2020 at 11:51:35AM +, Trammell Hudson wrote:
> This patch adds support for bundling the xen.efi hypervisor, the xen.cfg
> configuration file, the Linux kernel and initrd, as well as the XSM, and
> CPU microcode into a single "unified" EFI executable. The resulting EFI
> executa
Jan Beulich writes ("Re: [xen-unstable test] 153602: regressions - FAIL"):
> Actually, with also reverting 8d990807ec2c in the main tree (along with
> effectively reverting e013e8514389, which comes down to the same as Ian
> suggested for 165f3afbfc3d), and with its future re-installment at the
> s
On Friday, September 4, 2020 9:02 AM, Roger Pau Monné
wrote:
> On Fri, Aug 28, 2020 at 11:51:35AM +, Trammell Hudson wrote:
> > diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> > index 0273f79152..ba691b1890 100644
> > --- a/xen/arch/x86/xen.lds.S
> > +++ b/xen/a
flight 153706 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153706/
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
flight 153709 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153709/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm
> -Original Message-
> From: Jan Beulich
> Sent: 27 August 2020 08:09
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Wei Liu ; Roger
> Pau Monné
> ; Paul Durrant ; Jun Nakajima
> ; Kevin Tian
> ; George Dunlap
> Subject: [PATCH v3] x86/HVM: more consistently set I/O completi
branch xen-unstable
xenbranch xen-unstable
job build-i386-xsm
testid xen-build
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xe
Currently, xen.git#staging does not build in many environments because
of issues with minios master. This regression was introduced in an
uncontrolled manner by an update to mini-os.git#master.
This is because in e013e8514389 "config: use mini-os master for
unstable" we switched to tracking minio
On 04/09/2020 09:33, Jan Beulich wrote:
> On 01.09.2020 04:50, Igor Druzhinin wrote:
>> Guest kernel does need to know in some cases where the tables are located
>> to treat these regions properly. One example is kexec process where
>> the first kernel needs to pass firmware region locations to the
On 04.09.2020 16:47, Igor Druzhinin wrote:
> The referenced commit is not unrelated - it's the commit introducing the
> access
> causing kexec transition to fail. But I can add another one pointing to the
> mapping
> of ACPI tables that was supposed to fix the failure caused by the first one.
Oh
On Fri, Sep 04, 2020 at 10:53:26AM +0200, Jan Beulich wrote:
> On 01.09.2020 12:54, Roger Pau Monne wrote:
> > @@ -3290,11 +3288,6 @@ static int vmx_msr_write_intercept(unsigned int msr,
> > uint64_t msr_content)
> > __vmwrite(GUEST_IA32_DEBUGCTL, msr_content);
> > break;
> >
>
> On 2 Sep 2020, at 07:09, Jan Beulich wrote:
>
> We're not after any "fall-through" behavior here. Replace the constructs
> with ones understood by all conforming shells, including older bash
> (problem observed with 3.1.51(1)).
>
> Fixes: b51715f02bf9 ("tools/hotplug/Linux: remove code dupl
> On Sep 4, 2020, at 11:47 AM, George Dunlap wrote:
>
>
> If the volume of patches increases (or if filtering becomes more of an
> issue), then we might add a bot to look at the contents of the patch and tag
> the appropriate people (perhaps extending MAINTAINERS to include gitlab
> userna
> On Sep 4, 2020, at 11:49 AM, Bertrand Marquis
> wrote:
>
>>
>> I tried to add a comment and that is working well
>>
>> Remarks from my side:
>> - How can i ack/test/reject on this ?
>
> answer myself as i found the thumbs up that i have to click :-)
I have a button that says “Approve” —
> On Sep 4, 2020, at 11:20 AM, Jan Beulich wrote:
>
> On 04.09.2020 11:54, George Dunlap wrote:
>> At the community call last month as well as this, we discussed whether to
>> continue the “Gitlab experiment”. It was generally agreed that reviewing
>> Juergen’s long series was fairly sub-opt
On 04.09.2020 13:49, Igor Druzhinin wrote:
> On 04/09/2020 09:33, Jan Beulich wrote:
>> On 01.09.2020 04:50, Igor Druzhinin wrote:
>>> Guest kernel does need to know in some cases where the tables are located
>>> to treat these regions properly. One example is kexec process where
>>> the first kern
At the community call last month as well as this, we discussed whether to
continue the “Gitlab experiment”. It was generally agreed that reviewing
Juergen’s long series was fairly sub-optimal, and that email was more suited to
that sort of series.
That said, there was general agreement that re
flight 153668 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153668/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 152853
build-i386
On 04/09/2020 09:36, Jan Beulich wrote:
> On 01.09.2020 12:54, Roger Pau Monne wrote:
>> The SYSCFG, TOP_MEM1 and TOP_MEM2 MSRs are currently exposed to guests
>> and writes are silently discarded. Make this explicit in the SVM code
>> now, and just return default constant values when attempting to
On 04/09/2020 09:53, Jan Beulich wrote:
> On 01.09.2020 12:54, Roger Pau Monne wrote:
>> @@ -3290,11 +3288,6 @@ static int vmx_msr_write_intercept(unsigned int msr,
>> uint64_t msr_content)
>> __vmwrite(GUEST_IA32_DEBUGCTL, msr_content);
>> break;
>>
>> -case MSR_IA32_FEATU
flight 153700 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153700/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
On 04.09.2020 15:02, Roger Pau Monné wrote:
> On Fri, Aug 28, 2020 at 11:51:35AM +, Trammell Hudson wrote:
>> --- a/xen/arch/x86/xen.lds.S
>> +++ b/xen/arch/x86/xen.lds.S
>> @@ -156,6 +156,7 @@ SECTIONS
>> __note_gnu_build_id_end = .;
>>} :note :text
>> #elif defined(BUILD_ID_EFI)
On 04/09/2020 07:55, Jan Beulich wrote:
> On 03.09.2020 23:36, Andrew Cooper wrote:
>> There are multiple bugs with the existing implementation, including incorrect
>> comments.
>>
>> On AMD CPUs prior to Zen2, loading a NUL segment selector doesn't clear the
>> segment base, which is a problem for
On Thu, Sep 03, 2020 at 11:05:37AM +0100, Paul Durrant wrote:
> From: Paul Durrant
>
> The manpage for 'xl' documents that guest co-operation is required for a (non-
> forced) block-detach operation and that it may consequently fail. Currently,
> however, the implementation of generic device remo
On 04.09.2020 13:19, Trammell Hudson wrote:
> On Friday, September 4, 2020 5:54 AM, George Dunlap
> wrote:
>
>> And I’d encourage others to try submitting simple one-or-two-patch series as
>> PRs to Gitlab instead, as we continue the experiment.
>
> I've reworked my unified EFI image patch to
> On 4 Sep 2020, at 13:42, Jan Beulich wrote:
>
> On 04.09.2020 12:43, Bertrand Marquis wrote:
>>> On 4 Sep 2020, at 11:20, Jan Beulich wrote:
>>>
>>> On 04.09.2020 11:54, George Dunlap wrote:
At the community call last month as well as this, we discussed whether to
continue the “G
On Fri, Sep 04, 2020 at 09:00:18AM +0200, Jürgen Groß wrote:
> On 03.09.20 18:38, Roger Pau Monné wrote:
> > On Thu, Sep 03, 2020 at 05:30:07PM +0200, Jürgen Groß wrote:
> > > On 01.09.20 10:33, Roger Pau Monne wrote:
> > > > To be used in order to create foreign mappings. This is based on the
> >
On 04.09.2020 12:43, Bertrand Marquis wrote:
>> On 4 Sep 2020, at 11:20, Jan Beulich wrote:
>>
>> On 04.09.2020 11:54, George Dunlap wrote:
>>> At the community call last month as well as this, we discussed whether to
>>> continue the “Gitlab experiment”. It was generally agreed that reviewing
flight 153704 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153704/
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 01.09.20 10:33, Roger Pau Monne wrote:
Hello,
The following series contain some fixes in order to split Xen
unpopulated memory handling from the ballooning driver using the
ZONE_DEVICE functionality, so that physical memory regions used to map
foreign pages are not tied to memory hotplug.
No
On 04.09.20 10:42, Roger Pau Monné wrote:
On Fri, Sep 04, 2020 at 09:00:18AM +0200, Jürgen Groß wrote:
On 03.09.20 18:38, Roger Pau Monné wrote:
On Thu, Sep 03, 2020 at 05:30:07PM +0200, Jürgen Groß wrote:
On 01.09.20 10:33, Roger Pau Monne wrote:
To be used in order to create foreign mapping
On Friday, September 4, 2020 5:54 AM, George Dunlap
wrote:
> And I’d encourage others to try submitting simple one-or-two-patch series as
> PRs to Gitlab instead, as we continue the experiment.
I've reworked my unified EFI image patch to merge with the
recent Makefile changes and submitted it
Juergen Gross writes ("[PATCH] fix build with make 3.81"):
> make 3.81 doesn't support multiline variables defined with
>
> define var =
> ...
> endef
Reviewed-by: Ian Jackson
And commited, thanks.
Ian.
> On 4 Sep 2020, at 11:52, George Dunlap wrote:
>
>
>
>> On Sep 4, 2020, at 11:49 AM, Bertrand Marquis
>> wrote:
>>
>>>
>>> I tried to add a comment and that is working well
>>>
>>> Remarks from my side:
>>> - How can i ack/test/reject on this ?
>>
>> answer myself as i found the thumbs
> On 4 Sep 2020, at 11:43, Bertrand Marquis wrote:
>
>
>
>> On 4 Sep 2020, at 11:20, Jan Beulich wrote:
>>
>> On 04.09.2020 11:54, George Dunlap wrote:
>>> At the community call last month as well as this, we discussed whether to
>>> continue the “Gitlab experiment”. It was generally agre
> On 4 Sep 2020, at 11:20, Jan Beulich wrote:
>
> On 04.09.2020 11:54, George Dunlap wrote:
>> At the community call last month as well as this, we discussed whether to
>> continue the “Gitlab experiment”. It was generally agreed that reviewing
>> Juergen’s long series was fairly sub-optimal
On 04.09.2020 11:54, George Dunlap wrote:
> At the community call last month as well as this, we discussed whether to
> continue the “Gitlab experiment”. It was generally agreed that reviewing
> Juergen’s long series was fairly sub-optimal, and that email was more suited
> to that sort of serie
On Friday, September 4, 2020 5:29 AM, Julien Grall wrote:
> On 28/08/2020 12:51, Trammell Hudson wrote:
>
> > - /* PE32+ Subsystem type */
> > +#if defined(ARM)
> >
>
> Shouldn't this be defined(aarch64) ?
To be honest I'm not sure and don't have a way to check if
this code works on ARM. D
On 04.09.2020 11:44, Andrew Cooper wrote:
> On 04/09/2020 09:53, Jan Beulich wrote:
>> On 01.09.2020 12:54, Roger Pau Monne wrote:
>>> @@ -3290,11 +3288,6 @@ static int vmx_msr_write_intercept(unsigned int msr,
>>> uint64_t msr_content)
>>> __vmwrite(GUEST_IA32_DEBUGCTL, msr_content);
>>>
> -Original Message-
> From: Roger Pau Monné
> Sent: 04 September 2020 09:53
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Paul Durrant ; Ian
> Jackson
> ; Wei Liu ; Anthony PERARD
>
> Subject: Re: [PATCH 2/2] libxl: do not automatically force detach of block
> devices
>
>
On 04.09.2020 01:24, Sergey Temerkhanov wrote:
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -1521,7 +1521,9 @@ void __init efi_init_memory(void)
Looking at the line numbers - is this patch against the master
or staging branch? I ask because about as far away from the line
numbe
Hi,
On 28/08/2020 12:51, Trammell Hudson wrote:
+/* PE32+ Subsystem type */
+#if defined(__ARM__)
Shouldn't this be defined(__aarch64__) ?
+if (pe->FileHeader.Machine != PE_HEADER_MACHINE_ARM64)
+return NULL;
+#elif defined(__x86_64__)
+if (pe->FileHeader.Machine != PE_HE
On 11.02.2020 14:42, Sergey Dyasli wrote:
> Now a proper 2 patches series.
>
> Sergey Dyasli (2):
> xsm: add Kconfig option for denied string
> xsm: hide detailed Xen version from unprivileged guests
As we don't look to be coming to an agreement how to deal with the
situation, I'm going to dr
On 01.09.2020 12:54, Roger Pau Monne wrote:
> @@ -3290,11 +3288,6 @@ static int vmx_msr_write_intercept(unsigned int msr,
> uint64_t msr_content)
> __vmwrite(GUEST_IA32_DEBUGCTL, msr_content);
> break;
>
> -case MSR_IA32_FEATURE_CONTROL:
> -case MSR_IA32_VMX_BASIC ... M
flight 153678 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153678/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 151777
build-arm64-libvirt
> -Original Message-
> From: Jan Beulich
> Sent: 04 September 2020 09:16
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Wei Liu ;
> Roger Pau Monné ; Jun Nakajima
> ; Kevin Tian
> ; George Dunlap
> Subject: Ping: [PATCH v3] x86/HVM: more consistently set I/O
On 03.09.2020 10:15, Roger Pau Monné wrote:
> On Wed, Sep 02, 2020 at 10:02:33PM +0100, Andrew Cooper wrote:
>> On 01/09/2020 11:54, Roger Pau Monne wrote:
>>> @@ -1942,19 +1966,6 @@ static int svm_msr_read_intercept(unsigned int msr,
>>> uint64_t *msr_content)
>>> default:
>>> if (
On 01.09.2020 12:54, Roger Pau Monne wrote:
> The SYSCFG, TOP_MEM1 and TOP_MEM2 MSRs are currently exposed to guests
> and writes are silently discarded. Make this explicit in the SVM code
> now, and just return default constant values when attempting to read
> any of the MSRs, while continuing to
On 01.09.2020 12:54, Roger Pau Monne wrote:
> Such handling consist in checking that no bits have been changed from
> the read value, if that's the case silently drop the write, otherwise
> inject a fault.
>
> At least Windows guests will expect to write to the MISC_ENABLE MSR
> with the same valu
On 01.09.2020 04:50, Igor Druzhinin wrote:
> Guest kernel does need to know in some cases where the tables are located
> to treat these regions properly. One example is kexec process where
> the first kernel needs to pass firmware region locations to the second
> kernel which is now a requirement a
On 28.08.2020 18:02, Michael Kurth wrote:
> From: Michael Kurth
>
> Add "all_symbols" to all /tools/symbols calls so that
> xen-syms.map lists all symbols and not only .text section
> symbols. This change enhances debugging and livepatch
> capabilities.
>
> Signed-off-by: Michael Kurth
> Review
flight 153665 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153665/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 152332
build-amd64-xsm
On 27.08.2020 09:09, Jan Beulich wrote:
> Doing this just in hvm_emulate_one_insn() is not enough.
> hvm_ud_intercept() and hvm_emulate_one_vm_event() can get invoked for
> insns requiring one or more continuations, and at least in principle
> hvm_emulate_one_mmio() could, too. Without proper setti
flight 153694 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153694/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm
On 03.09.20 18:38, Roger Pau Monné wrote:
On Thu, Sep 03, 2020 at 05:30:07PM +0200, Jürgen Groß wrote:
On 01.09.20 10:33, Roger Pau Monne wrote:
To be used in order to create foreign mappings. This is based on the
ZONE_DEVICE facility which is used by persistent memory devices in
order to creat
94 matches
Mail list logo
