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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
>
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
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
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
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
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,
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:
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
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
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
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
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
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
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
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
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
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
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
>
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
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
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
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
---
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
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
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
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
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 ;
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
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
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
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
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.
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
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:
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
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
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
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
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
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 )
> {
On 05.08.2020 18:25, Andrew Cooper wrote:
> On 05/08/2020 15:54, Jan Beulich wrote:
>> On 05.08.2020 16:18, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpu/intel.c
>>> +++ b/xen/arch/x86/cpu/intel.c
>>> @@ -396,14 +396,14 @@ static void intel_log_freq(const struct cpuinfo_x86
>>> *c)
>>>
>>>
80 matches
Mail list logo
