On Fri, Dec 03, 2021 at 08:30:58AM +0100, Juergen Gross wrote:
> The size of the video memory of PVH guests should be set to 0 in case
> no value has been specified.
>
> Doing not so will leave it to be -1, resulting in an additional 1 kB
> of RAM being advertised in the memory map (here the outpu
On Thu, Dec 02, 2021 at 05:10:38PM +0100, Jan Beulich wrote:
> On 02.12.2021 17:03, Roger Pau Monné wrote:
> > On Fri, Sep 24, 2021 at 11:48:21AM +0200, Jan Beulich wrote:
> >> For vendor specific code to support superpages we need to be able to
> >> deal with a superpage mapping replacing an inter
On Fri, Sep 24, 2021 at 11:51:15AM +0200, Jan Beulich wrote:
> This is to aid diagnosing issues and largely matches VT-d's behavior.
> Since I'm adding permissions output here as well, take the opportunity
> and also add their displaying to amd_dump_page_table_level().
>
> Signed-off-by: Jan Beuli
On Fri, Dec 03, 2021 at 09:30:00AM +0100, Roger Pau Monné wrote:
> On Thu, Dec 02, 2021 at 05:10:38PM +0100, Jan Beulich wrote:
> > On 02.12.2021 17:03, Roger Pau Monné wrote:
> > > On Fri, Sep 24, 2021 at 11:48:21AM +0200, Jan Beulich wrote:
> > >> For vendor specific code to support superpages we
On 03.12.2021 09:30, Roger Pau Monné wrote:
> On Thu, Dec 02, 2021 at 05:10:38PM +0100, Jan Beulich wrote:
>> On 02.12.2021 17:03, Roger Pau Monné wrote:
>>> On Fri, Sep 24, 2021 at 11:48:21AM +0200, Jan Beulich wrote:
For vendor specific code to support superpages we need to be able to
d
On 03.12.2021 10:03, Roger Pau Monné wrote:
> On Fri, Sep 24, 2021 at 11:51:15AM +0200, Jan Beulich wrote:
>> This is to aid diagnosing issues and largely matches VT-d's behavior.
>> Since I'm adding permissions output here as well, take the opportunity
>> and also add their displaying to amd_dump_
On 03.12.2021 10:49, Jan Beulich wrote:
> On 03.12.2021 10:03, Roger Pau Monné wrote:
>> On Fri, Sep 24, 2021 at 11:51:15AM +0200, Jan Beulich wrote:
>>> This is to aid diagnosing issues and largely matches VT-d's behavior.
>>> Since I'm adding permissions output here as well, take the opportunity
Commit 68dcdf942326ad90ca527831afbee9cd4a867f84
(xen/arm: s/gic_set_guest_irq/gic_raise_guest_irq)
forgot to modify a comment about lr_pending list,
referring to a function that has been renamed.
Fix that.
Fixes: 68dcdf942326ad90ca527831afbee9cd4a867f84
Signed-off-by: Michal Orzel
---
xen/includ
On 03.12.2021 10:03, Roger Pau Monné wrote:
> On Fri, Sep 24, 2021 at 11:51:15AM +0200, Jan Beulich wrote:
>> This is to aid diagnosing issues and largely matches VT-d's behavior.
>> Since I'm adding permissions output here as well, take the opportunity
>> and also add their displaying to amd_dump_
Hi Michal,
> On 3 Dec 2021, at 09:58, Michal Orzel wrote:
>
> Commit 68dcdf942326ad90ca527831afbee9cd4a867f84
> (xen/arm: s/gic_set_guest_irq/gic_raise_guest_irq)
> forgot to modify a comment about lr_pending list,
> referring to a function that has been renamed.
> Fix that.
>
> Fixes: 68dcdf94
Assuming that the accounting for IOMMU page tables will also take care
of the P2M needs was wrong: dom0_paging_pages() can determine a far
higher value, high enough for the system to run out of memory while
setting up Dom0. Hence in the case of shared page tables the larger of
the two values needs
flight 167042 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167042/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm 22 guest-start/debian.repeat fail REGR. vs. 166912
test-amd64-i386-li
Certain notifications of Dom0 to Xen are independent of the mode Dom0 is
running in. Permit further PCI related ones (only their modern forms).
Also include the USB2 debug port operation at this occasion. While
largely relevant for the latter, drop the has_vpci() part of the
conditional as redundan
On 11/26/21 4:22 PM, Andrew Cooper wrote:
All calls through xsm_ops are fully altcall'd. Harden all fnptr targets.
This yields:
(XEN) altcall: Optimised away 197 endbr64 instructions
of 1655 on an everything-enabled build of Xen, which is ~12%.
Signed-off-by: Andrew Cooper
Reviewed-by:
When an IOMMU implements the full 16 bits worth of DID in context
entries, there's no point going through a memory base translation table.
For IOMMUs not using Caching Mode we can simply use the domain IDs
verbatim, while for Caching Mode we need to avoid DID 0.
Signed-off-by: Jan Beulich
---
For
On 11/26/21 7:33 AM, Andrew Cooper wrote:
Signed-off-by: Andrew Cooper
---
Reviewed-by: Daniel P. Smith
On 11/26/21 7:33 AM, Andrew Cooper wrote:
Signed-off-by: Andrew Cooper
---
Reviewed-by: Daniel P. Smith
On 12/1/21 6:15 AM, Andrew Cooper wrote:
Andrew Cooper (2):
xsm: Switch xsm_ops to __alt_call_maybe_initdata
xsm: Drop extern of non-existent variable
xen/include/xsm/xsm.h | 2 --
xen/xsm/xsm_core.c| 2 +-
2 files changed, 1 insertion(+), 3 deletions(-)
Reviewed-by: Daniel P. S
1: move efi-boot.h inclusion point
2: constify EFI_LOADED_IMAGE * function parameters
3: drop copy-in from QueryVariableInfo()'s OUT-only variable bouncing
Jan
When it was introduced, it was imo placed way too high up, making it
necessary to forward-declare way too many static functions. Move it down
together with
- the efi_check_dt_boot() stub, which afaict was deliberately placed
immediately ahead of the #include,
- blexit(), because of its use of the
Instead of altering Arm's forward declarations, drop them. Like
elsewhere we should limit such to cases where the first use lives ahead
of the definition.
Signed-off-by: Jan Beulich
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -44,20 +44,6 @@ void __flush_dcache_area(co
While be12fcca8b78 ("efi: fix alignment of function parameters in compat
mode") intentionally bounced them both ways to avoid any functional
change so close to the release of 4.16, the bouncing-in shouldn't really
be needed. In exchange the local variables need to gain initializers to
avoid copying
On 28.06.2021 13:56, Jan Beulich wrote:
> While going through uses of get_gpfn_from_mfn(), I've noticed
> some anomalies here (but of course there are more left). Patch
> 2 is specifically RFC, for altering the public interface.
>
> 1: adjustments to unmmap_broken_page()
> 2: change address space
Two fixes and some tidying.
1: HVM: permit CLFLUSH{,OPT} on execute-only code segments
2: HVM: fail virt-to-linear conversion for insn fetches from non-code segments
3: emul: drop "seg" parameter from insn_fetch() hook
Jan
On 12/2/2021 10:42 PM, Tom Lendacky wrote:
On 12/1/21 10:02 AM, Tianyu Lan wrote:
From: Tianyu Lan
In Isolation VM with AMD SEV, bounce buffer needs to be accessed via
extra address space which is above shared_gpa_boundary (E.G 39 bit
address line) reported by Hyper-V CPUID ISOLATION_CONFIG
On 03/12/2021 10:56, Jan Beulich wrote:
> When it was introduced, it was imo placed way too high up, making it
> necessary to forward-declare way too many static functions. Move it down
> together with
> - the efi_check_dt_boot() stub, which afaict was deliberately placed
> immediately ahead of t
The SDM explicitly permits this, and since that's sensible behavior
don't special case AMD (where the PM doesn't explicitly say so).
Fixes: 52dba7bd0b36 ("x86emul: generalize wbinvd() hook")
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x8
Just like (in protected mode) reads may not go to exec-only segments and
writes may not go to non-writable ones, insn fetches may not access data
segments.
Fixes: 623e83716791 ("hvm: Support hardware task switching")
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/
On 12/2/2021 10:39 PM, Wei Liu wrote:
+static bool hyperv_cc_platform_has(enum cc_attr attr)
+{
+#ifdef CONFIG_HYPERV
+ if (attr == CC_ATTR_GUEST_MEM_ENCRYPT)
+ return true;
+ else
+ return false;
This can be simplified as
return attr == CC_ATTR_G
On 03.12.2021 12:21, Andrew Cooper wrote:
> On 03/12/2021 10:56, Jan Beulich wrote:
>> When it was introduced, it was imo placed way too high up, making it
>> necessary to forward-declare way too many static functions. Move it down
>> together with
>> - the efi_check_dt_boot() stub, which afaict wa
On 12/2/2021 10:43 PM, Wei Liu wrote:
On Wed, Dec 01, 2021 at 11:02:54AM -0500, Tianyu Lan wrote:
[...]
diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index 46df59aeaa06..30fd0600b008 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@
On 03/12/2021 11:25, Jan Beulich wrote:
> On 03.12.2021 12:21, Andrew Cooper wrote:
>> On 03/12/2021 10:56, Jan Beulich wrote:
>>> When it was introduced, it was imo placed way too high up, making it
>>> necessary to forward-declare way too many static functions. Move it down
>>> together with
>>>
On 03/12/2021 10:19, Bertrand Marquis wrote:
Hi Michal,
On 3 Dec 2021, at 09:58, Michal Orzel wrote:
Commit 68dcdf942326ad90ca527831afbee9cd4a867f84
(xen/arm: s/gic_set_guest_irq/gic_raise_guest_irq)
forgot to modify a comment about lr_pending list,
referring to a function that has been re
This is specified (and asserted for in a number of places) to always be
CS. Passing this as an argument in various places is therefore
pointless. The price to pay is two simple new functions, with the
benefit of the PTWR case now gaining a more appropriate error code.
Signed-off-by: Jan Beulich
-
Hi Ayan,
> On 3 Dec 2021, at 11:23, Ayan Kumar Halder
> wrote:
>
>
>
> On 03/12/2021 10:19, Bertrand Marquis wrote:
>> Hi Michal,
>>> On 3 Dec 2021, at 09:58, Michal Orzel wrote:
>>>
>>> Commit 68dcdf942326ad90ca527831afbee9cd4a867f84
>>> (xen/arm: s/gic_set_guest_irq/gic_raise_guest_irq)
>
On 03/12/2021 11:21, Jan Beulich wrote:
> The SDM explicitly permits this, and since that's sensible behavior
> don't special case AMD (where the PM doesn't explicitly say so).
APM explicitly says so too.
"The CLFLUSH instruction executes at any privilege level. CLFLUSH
performs all the segmentat
On 03/12/2021 11:22, Jan Beulich wrote:
> Just like (in protected mode) reads may not go to exec-only segments and
> writes may not go to non-writable ones, insn fetches may not access data
> segments.
>
> Fixes: 623e83716791 ("hvm: Support hardware task switching")
> Signed-off-by: Jan Beulich
R
On 03.12.2021 12:48, Andrew Cooper wrote:
> On 03/12/2021 11:21, Jan Beulich wrote:
>> The SDM explicitly permits this, and since that's sensible behavior
>> don't special case AMD (where the PM doesn't explicitly say so).
>
> APM explicitly says so too.
>
> "The CLFLUSH instruction executes at a
Addressing some observations made while reviewing other patches. I'm
including the last patch here despite it largely duplicating one that
Jürgen did submit - there's one extra adjustment plus an open question
there.
1: perfc: conditionalize credit/credit2 counters
2: x86/perfc: conditionalize HVM
There's no point including them when the respective scheduler isn't
enabled in the build.
Signed-off-by: Jan Beulich
--- a/xen/include/xen/perfc_defn.h
+++ b/xen/include/xen/perfc_defn.h
@@ -37,6 +37,7 @@ PERFCOUNTER(tickled_busy_cpu, "sch
PERFCOUNTER(unit_check, "sched: unit_
There's no point including them when the respective functionality isn't
enabled in the build. Note that this covers only larger groups; more
fine grained exclusion may want to be done later on.
Signed-off-by: Jan Beulich
--- a/xen/include/asm-x86/perfc_defn.h
+++ b/xen/include/asm-x86/perfc_defn
This has gone out of sync over time. Introduce a simplistic mechanism to
hopefully keep things in sync going forward.
Signed-off-by: Jan Beulich
---
I wasn't sure about the #ifdef: Using CONFIG_PERF_COUNTERS there would
seem slightly odd next to a construct which specifically abstracts away
this
Hi Michal,
On 03/12/2021 09:58, Michal Orzel wrote:
Commit 68dcdf942326ad90ca527831afbee9cd4a867f84
(xen/arm: s/gic_set_guest_irq/gic_raise_guest_irq)
forgot to modify a comment about lr_pending list,
referring to a function that has been renamed.
Fix that.
Fixes: 68dcdf942326ad90ca527831afbee9
This has gone out of sync over time, resulting in NPF and XSETBV exits
incrementing the same counter. Introduce a simplistic mechanism to
hopefully keep things in better sync going forward.
Signed-off-by: Jan Beulich
---
Given their large (and growing) number, I wonder whether we shouldn't
fold "
This table must not have got updated in quite a while; tmem_op for
example has managed to not only appear since then, but also disappear
again (adding a name for it nevertheless, to make more obvious that
something strange is going on if the slot would ever have a non-zero
value).
Signed-off-by: J
Hi Julien,
On 03.12.2021 13:05, Julien Grall wrote:
> Hi Michal,
>
> On 03/12/2021 09:58, Michal Orzel wrote:
>> Commit 68dcdf942326ad90ca527831afbee9cd4a867f84
>> (xen/arm: s/gic_set_guest_irq/gic_raise_guest_irq)
>> forgot to modify a comment about lr_pending list,
>> referring to a function th
The 64-bit form forces %ecx to 0 while the 32-bit one so far didn't - it
only ended up that way when "pv_context" is zero. While presently no
leaf queried by callers has separate subleaves, let's avoid chancing it.
While there
- replace references to operands by number,
- relax constraints where p
On 03/12/2021 12:08, Michal Orzel wrote:
On 03.12.2021 13:05, Julien Grall wrote:
Hi Michal,
On 03/12/2021 09:58, Michal Orzel wrote:
Commit 68dcdf942326ad90ca527831afbee9cd4a867f84
(xen/arm: s/gic_set_guest_irq/gic_raise_guest_irq)
forgot to modify a comment about lr_pending list,
referrin
On 03/12/2021 11:23, Jan Beulich wrote:
> This is specified (and asserted for in a number of places) to always be
> CS. Passing this as an argument in various places is therefore
> pointless. The price to pay is two simple new functions,
This is actually a very interesting case study.
Both are in
Ashok,
On Thu, Dec 02 2021 at 16:45, Ashok Raj wrote:
> On Thu, Dec 02, 2021 at 09:40:08PM +0100, Thomas Gleixner wrote:
> Not worried about MSI-x for IDXD :), I assumed the purpose of this exercise
> was about 2 things.
>
> - Fix the VFIO mask/unmask weirdness ending up disable, reenable with mor
On 02.12.2021 15:10, Roger Pau Monné wrote:
> On Fri, Sep 24, 2021 at 11:47:41AM +0200, Jan Beulich wrote:
>> @@ -689,7 +763,8 @@ int __init dom0_construct_pv(struct doma
>> l1tab++;
>>
>> page = mfn_to_page(_mfn(mfn));
>> -if ( !page->u.inuse.type_info &&
>> +if
Hi Luca,
I have committed the patch with a couple of changes.
On 02/12/2021 15:05, Luca Fancellu wrote:
The example in section "UEFI boot and dom0less on ARM" has
a wrong compatible for the DTB passthrough, it is "ramdisk"
instead of "device-tree".
This patch fixes the example.
I have re-wrap
On Tue, Nov 23, 2021 at 02:20:47PM +0100, Juergen Gross wrote:
> Introduces the Xen pvUSB frontend. With pvUSB it is possible for a Xen
> domU to communicate with a USB device assigned to that domU. The
> communication is all done via the pvUSB backend in a driver domain
> (usually Dom0) which is o
On 03.12.2021 12:21, Andrew Cooper wrote:
> On 03/12/2021 10:56, Jan Beulich wrote:
>> When it was introduced, it was imo placed way too high up, making it
>> necessary to forward-declare way too many static functions. Move it down
>> together with
>> - the efi_check_dt_boot() stub, which afaict wa
On 03.12.21 13:49, Greg Kroah-Hartman wrote:
On Tue, Nov 23, 2021 at 02:20:47PM +0100, Juergen Gross wrote:
Introduces the Xen pvUSB frontend. With pvUSB it is possible for a Xen
domU to communicate with a USB device assigned to that domU. The
communication is all done via the pvUSB backend in a
Hi,
On 24/11/2021 07:59, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
vPCI may map and unmap PCI device memory (BARs) being passed through which
may take a lot of time. For this those operations may be deferred to be
performed later, so that they can be safely preempted.
Curre
flight 167055 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167055/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 13 nested-setupfail REGR. vs. 166942
test-arm64-arm64-li
On 26.11.2021 13:34, Andrew Cooper wrote:
> This is necessary for read_cr4() to function correctly. Move the EFER caching
> at the same time.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 26.11.2021 13:34, Andrew Cooper wrote:
> This allows us to have CET active much earlier in boot.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Hi Oleksandr,
On 24/11/2021 07:59, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
This is an assorted series of patches which aim is to make some further
basis for PCI passthrough on Arm support. The series continues the work
published earlier by Arm [1] and adds new helpers and c
flight 167073 xen-unstable-smoke real [real]
flight 167086 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167073/
http://logs.test-lab.xenproject.org/osstest/logs/167086/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
On 26.11.2021 13:34, Andrew Cooper wrote:
> For CET-IBT, we will need to optionally insert an endbr64 instruction at the
> start of the stub. Don't hardcode the jmp displacement assuming that it
> starts at byte 24 of the stub.
>
> Also add extra comments describing what is going on. The mix of
On 26.11.2021 13:34, Andrew Cooper wrote:
> Each IDT vector needs to land on an endbr64 instruction. This is especially
> important for the #CP handler, which will escalate to #DF if the endbr64 is
> missing.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
One remark though:
> @@ -
On 26.11.2021 13:34, Andrew Cooper wrote:
> Each IDT vector needs to land on an endbr64 instruction. This is especially
> important for the #CP handler, which will escalate to #DF if the endbr64 is
> missing.
One question here: How does this work? I don't recall there being any "CET
shadow" along
Hello,
Following the __ro_after_init work, I tried to complete a few pieces of
cleanup that I'd accrued, and everything has unravelled.
On x86, the __2M_* symbols haven't really been 2M aligned since their
introduction, and the utter mess that was _stext starting at 1M has long
since been cleared
On 26.11.2021 17:37, Andrew Cooper wrote:
> --- a/xen/arch/x86/extable.c
> +++ b/xen/arch/x86/extable.c
> @@ -129,19 +129,23 @@ search_exception_table(const struct cpu_user_regs *regs)
> static int __init cf_check stub_selftest(void)
> {
> static const struct {
> -uint8_t opc[4];
> +
On 26.11.2021 17:37, Andrew Cooper wrote:
> Each of MSR_{L,C}STAR and MSR_SYSENTER_EIP need to land on an endbr64
> instruction. For sysenter, this is easy.
>
> Unfortunately for syscall, the stubs are already 29 byte long with a limit of
> 32. endbr64 is 4 bytes. Luckily, there is a 1 byte ins
On 26.11.2021 17:33, Andrew Cooper wrote:
> ... to prevent the optimiser creating unsafe code. See the code comment for
> full details.
>
> Also add a build time check for endbr64 embedded in imm32 operands, which
> catches the obvious cases where the optimiser has done an unsafe thing.
But this
On 03/12/2021 13:17, Jan Beulich wrote:
> On 26.11.2021 13:34, Andrew Cooper wrote:
>> For CET-IBT, we will need to optionally insert an endbr64 instruction at the
>> start of the stub. Don't hardcode the jmp displacement assuming that it
>> starts at byte 24 of the stub.
>>
>> Also add extra comm
On 03.12.2021 14:59, Andrew Cooper wrote:
> On 03/12/2021 13:17, Jan Beulich wrote:
>> On 26.11.2021 13:34, Andrew Cooper wrote:
>>> For CET-IBT, we will need to optionally insert an endbr64 instruction at the
>>> start of the stub. Don't hardcode the jmp displacement assuming that it
>>> starts a
On 03/12/2021 13:59, Jan Beulich wrote:
> On 26.11.2021 17:33, Andrew Cooper wrote:
>> ... to prevent the optimiser creating unsafe code. See the code comment for
>> full details.
>>
>> Also add a build time check for endbr64 embedded in imm32 operands, which
>> catches the obvious cases where the
On 03/12/2021 13:23, Jan Beulich wrote:
> On 26.11.2021 13:34, Andrew Cooper wrote:
>> Each IDT vector needs to land on an endbr64 instruction. This is especially
>> important for the #CP handler, which will escalate to #DF if the endbr64 is
>> missing.
>>
>> Signed-off-by: Andrew Cooper
> Review
On 03/12/2021 13:34, Andrew Cooper wrote:
Hello,
Hi,
On ARM, the embedded dtb support wants a rethink, because it was placed
after BSS, rendering any space-saving null and void in the compiled (and
loaded) image.
While I understand the compiled/loaded image are going to be bigger, I
th
flight 167066 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167066/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
flight 167061 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167061/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 13 nested-setupfail REGR. vs. 165173
test-amd64-i386-xl-qemu
On 03/12/2021 13:32, Jan Beulich wrote:
> On 26.11.2021 13:34, Andrew Cooper wrote:
>> Each IDT vector needs to land on an endbr64 instruction. This is especially
>> important for the #CP handler, which will escalate to #DF if the endbr64 is
>> missing.
> One question here: How does this work?
Ho
Hi Jan,
> On 19 Nov 2021, at 10:20, Jan Beulich wrote:
>
> While going through their 5.15.3 log I did notice two changes, which made
> me go check what else we might be missing. The series here is the result.
> Linux has also updated zstd, but that includes a pretty large change which
> I'm not
On 03/12/2021 12:50, Jan Beulich wrote:
> On 03.12.2021 12:21, Andrew Cooper wrote:
>> On 03/12/2021 10:56, Jan Beulich wrote:
>>> When it was introduced, it was imo placed way too high up, making it
>>> necessary to forward-declare way too many static functions. Move it down
>>> together with
>>>
Le 03/12/2021 à 04:03, Joe Perches a écrit :
On Thu, 2021-12-02 at 20:07 +0100, Christophe JAILLET wrote:
Le 02/12/2021 à 19:16, Joe Perches a écrit :
On Thu, 2021-12-02 at 19:12 +0100, Christophe JAILLET wrote:
Le 02/12/2021 à 07:12, Juergen Gross a écrit :
On 01.12.21 22:10, Christophe JAIL
On Fri, 2021-12-03 at 16:54 +0100, Christophe JAILLET wrote:
> Le 03/12/2021 à 04:03, Joe Perches a écrit :
> > On Thu, 2021-12-02 at 20:07 +0100, Christophe JAILLET wrote:
> > > Le 02/12/2021 à 19:16, Joe Perches a écrit :
> > > > On Thu, 2021-12-02 at 19:12 +0100, Christophe JAILLET wrote:
> > >
On 23/11/2021 23:59, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
vPCI may map and unmap PCI device memory (BARs) being passed through which
may take a lot of time. For this those operations may be deferred to be
performed later, so that they can be safely preempted.
Currently
> On 3 Dec 2021, at 10:56, Jan Beulich wrote:
>
> When it was introduced, it was imo placed way too high up, making it
> necessary to forward-declare way too many static functions. Move it down
> together with
> - the efi_check_dt_boot() stub, which afaict was deliberately placed
> immediatel
> On 3 Dec 2021, at 10:57, Jan Beulich wrote:
>
> Instead of altering Arm's forward declarations, drop them. Like
> elsewhere we should limit such to cases where the first use lives ahead
> of the definition.
>
Reviewed-by: Luca Fancellu
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/ar
> On 3 Dec 2021, at 10:58, Jan Beulich wrote:
>
> While be12fcca8b78 ("efi: fix alignment of function parameters in compat
> mode") intentionally bounced them both ways to avoid any functional
> change so close to the release of 4.16, the bouncing-in shouldn't really
> be needed. In exchange t
On 30/09/2021 09:07, Dario Faggioli wrote:
> On Mon, 2021-09-27 at 09:51 +0200, Jan Beulich wrote:
>> On 24.09.2021 16:51, Dario Faggioli wrote:
>>> On Mon, 2021-09-20 at 18:25 +0100, Andrew Cooper wrote:
>>>
There is one buggy race record, TRC_RTDS_BUDGET_BURN. As it must
remain
__
> On 3 Dec 2021, at 12:03, Jan Beulich wrote:
>
> There's no point including them when the respective scheduler isn't
> enabled in the build.
>
Reviewed-by: Luca Fancellu
> Signed-off-by: Jan Beulich
>
> --- a/xen/include/xen/perfc_defn.h
> +++ b/xen/include/xen/perfc_defn.h
> @@ -37,6 +
flight 167081 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167081/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 20 guest-start/debianhvm.repeat fail REGR.
vs. 166961
test-amd64-amd
flight 167092 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167092/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt20 guest-start/debian.repeat fail REGR. vs. 166958
test-arm64-a
On 02/12/2021 08:01, Jan Beulich wrote:
> On 01.12.2021 20:07, Andrew Cooper wrote:
>> On 01/12/2021 08:20, Jan Beulich wrote:
>>> On 26.11.2021 22:22, Andrew Cooper wrote:
With altcall, we convert indirect branches into direct ones. With that
complete, none of the potential targets need
From: Tianyu Lan Sent: Wednesday, December 1, 2021 8:03 AM
>
> In Isolation VM, all shared memory with host needs to mark visible
> to host via hvcall. vmbus_establish_gpadl() has already done it for
> netvsc rx/tx ring buffer. The page buffer used by vmbus_sendpacket_
> pagebuffer() stills need
On 12/3/21 5:20 AM, Tianyu Lan wrote:
On 12/2/2021 10:42 PM, Tom Lendacky wrote:
On 12/1/21 10:02 AM, Tianyu Lan wrote:
From: Tianyu Lan
In Isolation VM with AMD SEV, bounce buffer needs to be accessed via
extra address space which is above shared_gpa_boundary (E.G 39 bit
address line) report
From: Tianyu Lan Sent: Wednesday, December 1, 2021 8:03 AM
>
> hyperv Isolation VM requires bounce buffer support to copy
> data from/to encrypted memory and so enable swiotlb force
> mode to use swiotlb bounce buffer for DMA transaction.
>
> In Isolation VM with AMD SEV, the bounce buffer needs
flight 167058 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167058/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 13 nested-setupfail REGR. vs. 166954
test-arm64-arm64-
On 12/3/21 1:11 PM, Tom Lendacky wrote:
On 12/3/21 5:20 AM, Tianyu Lan wrote:
On 12/2/2021 10:42 PM, Tom Lendacky wrote:
On 12/1/21 10:02 AM, Tianyu Lan wrote:
From: Tianyu Lan
In Isolation VM with AMD SEV, bounce buffer needs to be accessed via
extra address space which is above shared_gpa_
From: Oleksandr Tyshchenko
Rework Arm implementation to store grant table frame GFN
in struct page_info directly instead of keeping it in
standalone status/shared arrays. This patch is based on
the assumption that grant table page is the xenheap page.
To cover 64-bit/40-bit IPA on Arm64/Arm32 we
On 12/3/21 10:54 AM, Christophe JAILLET wrote:
Le 03/12/2021 à 04:03, Joe Perches a écrit :
On Thu, 2021-12-02 at 20:07 +0100, Christophe JAILLET wrote:
Le 02/12/2021 à 19:16, Joe Perches a écrit :
On Thu, 2021-12-02 at 19:12 +0100, Christophe JAILLET wrote:
Le 02/12/2021 à 07:12, Juergen G
flight 167071 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167071/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel 22 guest-start/debian.repeat fail REGR. vs.
166839
test-arm64-arm
flight 167083 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167083/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 18
guest-start/debianhvm.repeat fail REGR. vs.
flight 167089 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167089/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 13 nested-setupfail REGR. vs. 166942
test-arm64-arm64-xl
flight 167096 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167096/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 13 nested-setupfail REGR. vs. 165173
test-amd64-i386-libvirt
1 - 100 of 106 matches
Mail list logo
