flight 152501 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152501/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-pvshim12 guest-start fail never pass
test-amd64-i386-libvirt 13 migrate
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-5.9-rc1-tag
xen: branch for v5.9-rc1
It contains the following:
- two trivial comment fixes
- A small series for the Xen balloon driver fixing some issues
- A series of the Xen privcm
flight 152498 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152498/
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. 152418
Tests which did no
From: Stefano Stabellini
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
xen/include/public/xen.h | 567 ++-
1 file changed, 378 insertions(+), 189 deletions(-)
diff --git a/xen/include/public/xen.h b/x
From: Stefano Stabellini
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
xen/include/public/version.h | 74 +---
1 file changed, 60 insertions(+), 14 deletions(-)
diff --git a/xen/include/public/version.h b
From: Stefano Stabellini
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
xen/include/public/hvm/params.h | 158 +---
1 file changed, 124 insertions(+), 34 deletions(-)
diff --git a/xen/include/public/hvm/params
From: Stefano Stabellini
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
xen/include/public/grant_table.h | 443 ++-
1 file changed, 257 insertions(+), 186 deletions(-)
diff --git a/xen/include/public/grant_tab
From: Stefano Stabellini
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
xen/include/public/vcpu.h | 180 --
1 file changed, 136 insertions(+), 44 deletions(-)
diff --git a/xen/include/public/vcpu.h b/x
From: Stefano Stabellini
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
xen/include/public/sched.h | 129 ++---
1 file changed, 92 insertions(+), 37 deletions(-)
diff --git a/xen/include/public/sched.h b/x
From: Stefano Stabellini
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
xen/include/public/hypfs.h | 72 --
1 file changed, 45 insertions(+), 27 deletions(-)
diff --git a/xen/include/public/hypfs.h b/x
From: Stefano Stabellini
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
xen/include/public/device_tree_defs.h | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/xen/include/public/device_tree_de
From: Stefano Stabellini
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
xen/include/public/elfnote.h | 109 ++-
1 file changed, 81 insertions(+), 28 deletions(-)
diff --git a/xen/include/public/elfnote.h b
From: Stefano Stabellini
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
xen/include/public/memory.h | 232
1 file changed, 155 insertions(+), 77 deletions(-)
diff --git a/xen/include/public/memory.h b
From: Stefano Stabellini
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
xen/include/public/features.h | 78 ++-
1 file changed, 59 insertions(+), 19 deletions(-)
diff --git a/xen/include/public/features.h
On Thu, 6 Aug 2020, Julien Grall wrote:
> On 06/08/2020 01:37, Stefano Stabellini wrote:
> > On Wed, 5 Aug 2020, Julien Grall wrote:
> > > On 04/08/2020 20:11, Stefano Stabellini wrote:
> > > > On Tue, 4 Aug 2020, Julien Grall wrote:
> > > > > On 04/08/2020 12:10, Oleksandr wrote:
> > > > > > On 04
On Thu, 6 Aug 2020, Julien Grall wrote:
> On 06/08/2020 01:37, Stefano Stabellini wrote:
> > On Wed, 5 Aug 2020, Julien Grall wrote:
> > > On 05/08/2020 00:22, Stefano Stabellini wrote:
> > > > On Mon, 3 Aug 2020, Oleksandr Tyshchenko wrote:
> > > > > From: Oleksandr Tyshchenko
> > > > >
> > > >
From: Stefano Stabellini
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
xen/include/public/hvm/hvm_op.h | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/xen/include/public/hvm/hvm_op.h b/xen/includ
From: Stefano Stabellini
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
xen/include/public/arch-arm.h | 43 ++-
1 file changed, 27 insertions(+), 16 deletions(-)
diff --git a/xen/include/public/arch-arm.h
From: Stefano Stabellini
Convert in-code comments to kernel-doc format wherever possible.
Signed-off-by: Stefano Stabellini
---
xen/include/public/event_channel.h | 188 +++--
1 file changed, 121 insertions(+), 67 deletions(-)
diff --git a/xen/include/public/event_chan
On Thu, 6 Aug 2020, Jan Beulich wrote:
> On 06.08.2020 02:37, Stefano Stabellini wrote:
> > What should do_trap_stage2_abort_guest do on IO_RETRY? Simply return
> > early and let the scheduler do its job? Something like:
> >
> > enum io_state state = try_handle_mmio(regs, hsr, gpa);
>
flight 152497 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152497/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-rtds 15 guest-stop fail blocked in 152480
test-amd64-amd64-xl-qemuu-win7-amd6
flight 152492 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152492/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 152332
test-amd64-i386-qem
On 06/08/2020 10:28, Jan Beulich wrote:
> Note that opt_pv32's declaration / #define need to be moved due to other
> header dependencies; in particular can asm-x86/mm.h not include
> asm-x86/pv/domain.h.
While I do appreciate that our headers are a complete tangle, I can't
help but feel that this
On 06/08/2020 15:15, Trammell Hudson wrote:
> On Thursday, August 6, 2020 2:04 PM, Jan Beulich wrote:
>
>> On 06.08.2020 13:44, Trammell Hudson wrote:
>>
>>> On Thursday, August 6, 2020 9:57 AM, Jan Beulich jbeul...@suse.com wrote:
Also, considering kernel and initrd are embedded, is there re
On Thursday, August 6, 2020 6:40 PM, Jan Beulich wrote:
> On 05.08.2020 20:19, Trammell Hudson wrote:
> [...]
> > ~/build/xen-clean/xen$ objcopy xen.efi test.efi
> > objcopy: test.efi: Data Directory size (1c) exceeds space left in section
> > (18)
> > objcopy: test.efi: error copying private BF
flight 152502 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152502/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
On 06.08.20 19:33, Jan Beulich wrote:
Hi Jan.
On 06.08.2020 16:28, Oleksandr wrote:
On 06.08.20 14:50, Jan Beulich wrote:
Hi Jan
On 03.08.2020 20:21, Oleksandr Tyshchenko wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1652,6 +1652,12 @@ long do_memory_op(unsigned long cmd
On 05.08.2020 20:19, Trammell Hudson wrote:
> When building xen from head with almost any combination of options, the
> resulting xen.efi seems properly formed. When CONFIG_LIVEPATCH is turned off,
> however, the resulting xen.efi is corrupted in some way and binutils no
> longer wants to work w
On 06.08.2020 16:15, Trammell Hudson wrote:
> On Thursday, August 6, 2020 2:04 PM, Jan Beulich wrote:
>> On 06.08.2020 13:44, Trammell Hudson wrote:
>>> On Thursday, August 6, 2020 9:57 AM, Jan Beulich jbeul...@suse.com wrote:
Overall I think it might help if this PE parsing code (if UEFI
>>>
On 06.08.2020 16:28, Oleksandr wrote:
>
> On 06.08.20 14:50, Jan Beulich wrote:
>
> Hi Jan
>
On 03.08.2020 20:21, Oleksandr Tyshchenko wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -1652,6 +1652,12 @@ long do_memory_op(unsigned long cmd,
> XEN_GUEST_HA
On 06/08/2020 10:05, Jan Beulich wrote:
> We're gaining such sections, and like .text.* and .data.* they shouldn't
> be present in objects subject to automatic to-init conversion. Oddly
> enough for quite some time we did have an instance breaking this rule,
> which gets fixed at this occasion, by
On 06/08/2020 10:05, Jan Beulich wrote:
> The originally used sed expression converted not just multiple leading
> zeroes (as intended), but also trailing ones, rendering the error
> message somewhat confusing. Collapse zeroes in just the one place where
> we need them collapsed, and leave objdump'
On 06/08/2020 10:14, Jan Beulich wrote:
> On 06.08.2020 11:07, Julien Grall wrote:
>> On 06/08/2020 10:04, Jan Beulich wrote:
>>> Older bash fails to honor "set -e" for certain built-in commands
>> "Older" is pretty vague. May I ask the exact version you run into the issue?
> If I knew in what vers
On 06.08.20 14:50, Jan Beulich wrote:
Hi Jan
On 03.08.2020 20:21, Oleksandr Tyshchenko wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1652,6 +1652,12 @@ long do_memory_op(unsigned long cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)
break;
}
+/* x86 already
On Thursday, August 6, 2020 2:04 PM, Jan Beulich wrote:
> On 06.08.2020 13:44, Trammell Hudson wrote:
>
> > On Thursday, August 6, 2020 9:57 AM, Jan Beulich jbeul...@suse.com wrote:
> >
> > > Overall I think it might help if this PE parsing code (if UEFI
> > > doesn't offer a protocol to do it fo
On 06/08/2020 10:28, Jan Beulich wrote:
> Add #ifdef-s (the 2nd one will be needed in particular, to guard the
> uses of m2p_compat_vstart and HYPERVISOR_COMPAT_VIRT_START()) and fold
> duplicate uses of elf_32bit().
>
> Also adjust what gets logged: Avoid "compat32" when support isn't built
> in,
On 06.08.20 14:08, Julien Grall wrote:
Hi Julien
What is this function supposed to do?
Agree, sounds confusing a bit. I assume it is supposed to complete
Guest MMIO access after finishing emulation.
Shall I rename it to something appropriate (maybe by adding ioreq
prefix)?
How about i
On 04.08.2020 15:42, Paul Durrant wrote:
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1772,13 +1772,14 @@ static int __must_check intel_iommu_map_page(struct
> domain *d, dfn_t dfn,
> old = *pte;
>
> dma_set_pte_addr(new, mfn_to_maddr(mf
On 04.08.2020 15:42, Paul Durrant wrote:
> @@ -208,35 +209,53 @@ struct root_entry {
> do { (r).ctp = ((val) >> PAGE_SHIFT_4K); } while (0)
>
> struct context_entry {
> -u64 lo;
> -u64 hi;
> +union {
> +__uint128_t val;
> +struct { uint64_t lo, hi; };
> +
On 04.08.2020 15:42, Paul Durrant wrote:
> --- a/xen/drivers/passthrough/vtd/iommu.h
> +++ b/xen/drivers/passthrough/vtd/iommu.h
> @@ -184,21 +184,28 @@
> #define dma_frcd_source_id(c) (c & 0x)
> #define dma_frcd_page_addr(d) (d & (((u64)-1) << 12)) /* low 64 bit */
>
> -/*
> - * 0: Present
On 04.08.2020 15:42, Paul Durrant wrote:
> @@ -553,14 +549,7 @@ static void iommu_dump_p2m_table(unsigned char key)
> if ( is_hardware_domain(d) || !is_iommu_enabled(d) )
> continue;
>
> -if ( iommu_use_hap_pt(d) )
> -{
> -printk("\ndomain%d IOMMU
On 04.08.2020 15:42, Paul Durrant wrote:
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -318,6 +318,48 @@ static u64 addr_to_dma_page_maddr(struct domain *domain,
> u64 addr, int alloc)
> return pte_maddr;
> }
>
> +static uint64_t domain_pgd_ma
flight 152495 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152495/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e188ecc8b4aed8fdd26b731d43883861f5e5e7b4
baseline version:
ovmf aa211bb6ef8edc70d2e6d
On 06.08.2020 13:44, Trammell Hudson wrote:
> On Thursday, August 6, 2020 9:57 AM, Jan Beulich wrote:
>> Overall I think it might help if this PE parsing code (if UEFI
>> doesn't offer a protocol to do it for us) was put into its own
>> source file.
>
> I tried to putting it into a separate file
On 06.08.2020 13:35, Julien Grall wrote:
> On 05/08/2020 17:21, Jan Beulich wrote:
>> On 03.08.2020 20:21, Oleksandr Tyshchenko wrote:
>>> --- a/xen/common/memory.c
>>> +++ b/xen/common/memory.c
>>> @@ -1652,6 +1652,12 @@ long do_memory_op(unsigned long cmd,
>>> XEN_GUEST_HANDLE_PARAM(void) arg)
>
On 04.08.2020 15:42, Paul Durrant wrote:
> From: Paul Durrant
>
> This patch avoids calling iommu_iotlb_flush() for each individual GNTTABOP and
> insteads calls iommu_iotlb_flush_all() at the end of the hypercall. This
> should mean batched map/unmap operations perform better but may be slightly
On Thursday, August 6, 2020 9:57 AM, Jan Beulich wrote:
> On 05.08.2020 19:20, Trammell Hudson wrote:
> > This preliminary patch adds support for bundling the Xen hypervisor,
> > xen.cfg,
> > the Linux kernel, initrd and XSM into a single "unified" EFI executable that
> > can be signed by sbsignt
On 04.08.2020 15:42, Paul Durrant wrote:
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -274,6 +274,10 @@ int iommu_map(struct domain *d, dfn_t dfn, mfn_t mfn,
> break;
> }
>
> +/* Something went wrong so flush everything and clear flush fla
On 05.08.20 16:30, Julien Grall wrote:
Hi,
Hi Julien
On 03/08/2020 19:21, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
As a lot of x86 code can be re-used on Arm later on, this patch
splits IOREQ support into common and arch specific parts.
This support is going to be used o
Hi Jan,
On 05/08/2020 17:21, Jan Beulich wrote:
On 03.08.2020 20:21, Oleksandr Tyshchenko wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1652,6 +1652,12 @@ long do_memory_op(unsigned long cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)
break;
}
+/* x86 already set
Hi Stefano,
On 06/08/2020 01:37, Stefano Stabellini wrote:
On Wed, 5 Aug 2020, Julien Grall wrote:
On 05/08/2020 00:22, Stefano Stabellini wrote:
On Mon, 3 Aug 2020, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch adds ability to the device emulator to notify otherend
(som
On 06.08.2020 13:08, Julien Grall wrote:
> On 05/08/2020 20:30, Oleksandr wrote:
>> I was thinking how to split handle_hvm_io_completion()
>> gracefully but I failed find a good solution for that, so decided to add
>> two stubs (msix_write_completion and handle_realmode_completion) on Arm.
>> I
On 05/08/2020 20:30, Oleksandr wrote:
On 05.08.20 17:12, Julien Grall wrote:
Hi,
Hi Julien
On 03/08/2020 19:21, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch makes possible to forward Guest MMIO accesses
to a device emulator on Arm and enables that support for
Ar
On 04.08.2020 15:42, Paul Durrant wrote:
> The 'legacy' functions do implicit flushing so amend the callers to do the
> appropriate flushing.
>
> Unfortunately, because of the structure of the P2M code, we cannot remove
> the per-CPU 'iommu_dont_flush_iotlb' global and the optimization it
> facili
Hi,
On 05/08/2020 16:41, Oleksandr wrote:
On 05.08.20 12:32, Julien Grall wrote:
Hi Julien.
Hi Stefano,
On 05/08/2020 00:22, Stefano Stabellini wrote:
On Mon, 3 Aug 2020, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch makes possible to forward Guest MMIO accesses
to a
On 04.08.2020 15:42, Paul Durrant wrote:
> From: Paul Durrant
>
> At the moment iommu_map() and iommu_unmap() take a page order but not a
> count, whereas iommu_iotlb_flush() takes a count but not a page order.
> This patch simply makes them consistent with each other.
Why can't we do with just
Hi,
On 06/08/2020 01:37, Stefano Stabellini wrote:
On Wed, 5 Aug 2020, Julien Grall wrote:
On 04/08/2020 20:11, Stefano Stabellini wrote:
On Tue, 4 Aug 2020, Julien Grall wrote:
On 04/08/2020 12:10, Oleksandr wrote:
On 04.08.20 10:45, Paul Durrant wrote:
+static inline bool hvm_ioreq_needs_
On 06/08/2020 10:25, Jan Beulich wrote:
On 06.08.2020 11:20, Julien Grall wrote:
On 06/08/2020 10:14, Jan Beulich wrote:
I've observed it with 3.2.57(2).
Thank you. Please mention it in the commit message.
Well, added. If I had seen any use of the precise version, I would
have done so right
While in most cases code ahead of the invocation of set_gpfn_from_mfn()
deals with shared pages, at least in set_typed_p2m_entry() I can't spot
such handling (it's entirely possible there's code missing there). Let's
try to play safe and add an extra check.
Signed-off-by: Jan Beulich
--- a/xen/i
Note that opt_pv32's declaration / #define need to be moved due to other
header dependencies; in particular can asm-x86/mm.h not include
asm-x86/pv/domain.h.
While touching their definitions anyway, also adjust section placement
of m2p_compat_vstart and compat_idle_pg_table_l2. Similarly, while
pu
Add #ifdef-s (the 2nd one will be needed in particular, to guard the
uses of m2p_compat_vstart and HYPERVISOR_COMPAT_VIRT_START()) and fold
duplicate uses of elf_32bit().
Also adjust what gets logged: Avoid "compat32" when support isn't built
in, and don't assume ELF class <> ELFCLASS64 means ELFC
On 06.08.2020 11:22, Oleksandr wrote:
>
> On 05.08.20 19:40, Paul Durrant wrote:
>
> Hi Jan, Paul
>
>>> -Original Message-
>>> From: Jan Beulich
>>> Sent: 05 August 2020 17:20
>>> To: Oleksandr Tyshchenko ; Paul Durrant
>>> Cc: xen-devel@lists.xenproject.org; Oleksandr Tyshchenko
>>>
On 06.08.2020 11:20, Julien Grall wrote:
> On 06/08/2020 10:14, Jan Beulich wrote:
>> I've observed it with 3.2.57(2).
>
> Thank you. Please mention it in the commit message.
Well, added. If I had seen any use of the precise version, I would
have done so right away. Would you mind educating me ho
As pointed out by Andrew, maintaining the compat M2P when !PV32
(or when "pv=no-32" was given) is a pointless waste of memory. Do
away with this, with a possible plan to subsequently use the
compat instance instead of the native one in shim mode with a
32-bit guest (requiring more intrusive rework,
On 05.08.20 19:40, Paul Durrant wrote:
Hi Jan, Paul
-Original Message-
From: Jan Beulich
Sent: 05 August 2020 17:20
To: Oleksandr Tyshchenko ; Paul Durrant
Cc: xen-devel@lists.xenproject.org; Oleksandr Tyshchenko
; Andrew
Cooper ; George Dunlap ;
Ian Jackson
; Julien Grall ; Stefa
On 06/08/2020 10:14, Jan Beulich wrote:
On 06.08.2020 11:07, Julien Grall wrote:
On 06/08/2020 10:04, Jan Beulich wrote:
Older bash fails to honor "set -e" for certain built-in commands
"Older" is pretty vague. May I ask the exact version you run into the issue?
If I knew in what version
On Tue, Aug 04, 2020 at 06:35:20AM +, Oleksandr Andrushchenko wrote:
>
> On 8/4/20 9:12 AM, Jürgen Groß wrote:
> > On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
> >> From: Oleksandr Andrushchenko
> >>
> >> The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
> >> display fronten
Looks great! Thanks.
Reviewed-by: Dan Carpenter
regards,
dan carpenter
On 06.08.2020 11:07, Julien Grall wrote:
> On 06/08/2020 10:04, Jan Beulich wrote:
>> Older bash fails to honor "set -e" for certain built-in commands
>
> "Older" is pretty vague. May I ask the exact version you run into the issue?
If I knew in what version the issue got fixed, I'd have specified
Hi Jan,
On 06/08/2020 10:04, Jan Beulich wrote:
Older bash fails to honor "set -e" for certain built-in commands
"Older" is pretty vague. May I ask the exact version you run into the issue?
("while" here), despite the command's status correctly bein non-zero.
The subsequent objcopy invocatio
Address at least the primary reason why 52bba67f8b87 ("efi/boot: Don't
free ebmalloc area at all") was put in place: Make xen_in_range() aware
of the freed range. This is in particular relevant for EFI-enabled
builds not actually running on EFI, as the entire range will be unused
in this case.
Sig
We're gaining such sections, and like .text.* and .data.* they shouldn't
be present in objects subject to automatic to-init conversion. Oddly
enough for quite some time we did have an instance breaking this rule,
which gets fixed at this occasion, by breaking out the EFI boot
allocator functions in
The originally used sed expression converted not just multiple leading
zeroes (as intended), but also trailing ones, rendering the error
message somewhat confusing. Collapse zeroes in just the one place where
we need them collapsed, and leave objdump's output as is for all other
purposes.
Fixes: 4
Older bash fails to honor "set -e" for certain built-in commands
("while" here), despite the command's status correctly bein non-zero.
The subsequent objcopy invocation now being separated by a semicolon
results in no failure. Insert an explicit "exit" (replacing ; by &&
ought to be another possibl
Initially I merely noticed the regression addressed by the 1st patch,
but looking more closely revealed further deficiencies. After having
moved the FIXME in patch 3 I couldn't resist and address that issue
at least partly (patch 4), seeing that three and a half years have
passed and nothing was do
On 05.08.2020 20:30, Andrew Cooper wrote:
> On 05/08/2020 19:19, Trammell Hudson wrote:
>> When building xen from head with almost any combination of options, the
>> resulting xen.efi seems properly formed. When CONFIG_LIVEPATCH is turned
>> off, however, the resulting xen.efi is corrupted in som
On 05.08.20 19:15, Andrew Cooper wrote:
Hi Andrew
On 03/08/2020 19:21, Oleksandr Tyshchenko wrote:
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 06881d0..f6fc3f8 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -70,6 +70,7 @@ extra-y := symbols-dummy.o
obj-$(
On 05.08.2020 19:20, Trammell Hudson wrote:
> This preliminary patch adds support for bundling the Xen hypervisor, xen.cfg,
> the Linux kernel, initrd and XSM into a single "unified" EFI executable that
> can be signed by sbsigntool for verification by UEFI Secure Boot. It is
> inspired by syst
On 06.08.2020 02:37, Stefano Stabellini wrote:
> What should do_trap_stage2_abort_guest do on IO_RETRY? Simply return
> early and let the scheduler do its job? Something like:
>
> enum io_state state = try_handle_mmio(regs, hsr, gpa);
>
> switch ( state )
> {
>
79 matches
Mail list logo
