When a static domain populates memory through populate_physmap at runtime,
it shall retrieve reserved pages from resv_page_list to make sure that
guest RAM is still restricted in statically configured memory regions.
This commit also introduces a new helper acquire_reserved_page to make it work.
Later, we want to use acquire_domstatic_pages() for populating memory
for static domain on runtime, however, there are a lot of pointless work
(checking mfn_valid(), scrubbing the free part, cleaning the cache...)
considering we know the page is valid and belong to the guest.
This commit splits
Today when a domain unpopulates the memory on runtime, they will always
hand the memory back to the heap allocator. And it will be a problem if domain
is static.
Pages as guest RAM for static domain shall be reserved to only this domain
and not be used for any other purposes, so they shall never
In order to have an easy and quick way to find out whether this domain memory
is statically configured, this commit introduces a new flag CDF_staticmem and a
new helper is_domain_using_staticmem() to tell.
Signed-off-by: Penny Zheng
Acked-by: Julien Grall
Acked-by: Jan Beulich
---
v9 changes:
With more and more CDF_xxx internal flags in and to save the space, this
commit introduces a new field "flags" in struct domain to store CDF_*
internal flags directly.
Another new CDF_xxx will be introduced in the next patch.
Signed-off-by: Penny Zheng
Acked-by: Julien Grall
---
v9 changes:
-
Pages used as guest RAM for static domain, shall be reserved to this
domain only.
So in case reserved pages being used for other purpose, users
shall not free them back to heap, even when last ref gets dropped.
This commit introduces a new helper free_domstatic_page to free
static page in
The code in free_heap_pages() will try to merge pages with the
successor/predecessor if pages are suitably aligned. So if the pages
reserved are right next to the pages given to the heap allocator,
free_heap_pages() will merge them, and give the reserved pages to heap
allocator accidently as a
PGC_reserved could be ambiguous, and we have to tell what the pages are
reserved for, so this commit intends to rename PGC_reserved to
PGC_static, which clearly indicates the page is reserved for static
memory.
Signed-off-by: Penny Zheng
Acked-by: Jan Beulich
Acked-by: Julien Grall
---
v8
Today when a domain unpopulates the memory on runtime, they will always
hand the memory over to the heap allocator. And it will be a problem if it
is a static domain.
Pages used as guest RAM for static domain shall always be reserved to this
domain only, and not be used for any other purposes, so
flight 171693 qemu-mainline real [real]
flight 171698 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171693/
http://logs.test-lab.xenproject.org/osstest/logs/171698/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
So, you think it's a problem with fc36?
Original message From: Andrew Cooper
Date: 7/18/22 6:25 PM (GMT-05:00) To:
ch...@dalessio.org, xen-devel@lists.xenproject.org Cc: Jan Beulich
, Michael Young Subject: Re: Panic
on CPU 0: FATAL TRAP: vec 7, #NM[] On 18/07/2022
Hi Oleksandr,
We have tested it on arm64 with " disk = [ 'phy:/usr/share/guests/disk.img0,
xvda1, backendtype=standalone, specification=virtio']". It works ok.
Tested-by: Jiamei Xie
Tested-by: Henry Wang
Best wishes
Jiamei Xie
> -Original Message-
> From: Xen-devel On Behalf Of
>
From: Peter Zijlstra
[ Upstream commit b75b7f8ef1148be1b9321ffc2f6c19238904b438 ]
Native SYS{CALL,ENTER} entry points are called
entry_SYS{CALL,ENTER}_{64,compat}, make sure the Xen versions are
named consistently.
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Borislav Petkov
On 7/15/22 10:25 AM, Juergen Gross wrote:
> Today PAT is usable only with MTRR being active, with some nasty tweaks
> to make PAT usable when running as Xen PV guest, which doesn't support
> MTRR.
>
> The reason for this coupling is, that both, PAT MSR changes and MTRR
> changes, require a similar
From: Peter Zijlstra
[ Upstream commit b75b7f8ef1148be1b9321ffc2f6c19238904b438 ]
Native SYS{CALL,ENTER} entry points are called
entry_SYS{CALL,ENTER}_{64,compat}, make sure the Xen versions are
named consistently.
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Borislav Petkov
From: Peter Zijlstra
[ Upstream commit 9bb2ec608a209018080ca262f771e6a9ff203b6f ]
Update retpoline validation with the new CONFIG_RETPOLINE requirement of
not having bare naked RET instructions.
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Borislav Petkov
Reviewed-by: Josh Poimboeuf
> I'd focus on the booting issues first. And I guess you can take a video
> of that (assuming that a single screenshot likely isn't going to be
> enough), possibly with "vga=keep" in place (albeit that introduces
> extra slowness)?
>
> There's also the option of using an EHCI debug port for the
flight 171686 xen-unstable real [real]
flight 171692 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171686/
http://logs.test-lab.xenproject.org/osstest/logs/171692/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 171691 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171691/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 671b0cea510ad6de02ee9d6dbdf8f9bbb881f35d
baseline version:
ovmf
flight 171683 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171683/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 14 guest-start fail REGR. vs. 171676
Tests which did not
On 19/07/2022 21:08, Jason Andryuk wrote:
> commit e46474278a0e ("x86/intel: Expose MSR_ARCH_CAPS to dom0") started
> exposing MSR_ARCH_CAPS to dom0. More bits in MSR_ARCH_CAPS have since
> been defined, but they haven't been exposed. Update the list to allow
> them through.
>
> As one example,
On 19/07/2022 13:56, Jan Beulich wrote:
> Already ISE rev 044 added text to this effect; rev 045 further dropped
> leftover earlier text indicating the contrary:
> - ENQCMD requires the low 32 bits of the memory operand to be clear,
> - ENDCMDS requires bits 20...30 of the memory operand to be
commit e46474278a0e ("x86/intel: Expose MSR_ARCH_CAPS to dom0") started
exposing MSR_ARCH_CAPS to dom0. More bits in MSR_ARCH_CAPS have since
been defined, but they haven't been exposed. Update the list to allow
them through.
As one example, this allows a linux Dom0 to know that it has the
Hi Dan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on xen-tip/linux-next]
[also build test WARNING on linus/master v5.19-rc7 next-20220719]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
flight 171689 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171689/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 19a87683654a4969a9f86a3d02199c253c789970
baseline version:
ovmf
On Tue, Jul 19, 2022 at 2:23 PM Andrew Cooper wrote:
>
> On 19/07/2022 18:18, Tamas K Lengyel wrote:
> > diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
> > index d2c03a1104..2b5d64a60d 100644
> > --- a/xen/arch/x86/cpu/vpmu.c
> > +++ b/xen/arch/x86/cpu/vpmu.c
> > @@ -529,6 +529,16
flight 171687 seabios real [real]
flight 171690 seabios real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171687/
http://logs.test-lab.xenproject.org/osstest/logs/171690/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 171688 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171688/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
From: Oleksandr Andrushchenko
Take into account guest's BAR view and program its p2m accordingly:
gfn is guest's view of the BAR and mfn is the physical BAR value as set
up by the PCI bus driver in the hardware domain.
This way hardware domain sees physical BAR values and guest sees
emulated
From: Oleksandr Andrushchenko
There are three originators for the PCI configuration space access:
1. The domain that owns physical host bridge: MMIO handlers are
there so we can update vPCI register handlers with the values
written by the hardware domain, e.g. physical view of the registers
vs
From: Oleksandr Andrushchenko
Assign SBDF to the PCI devices being passed through with bus 0.
The resulting topology is where PCIe devices reside on the bus 0 of the
root complex itself (embedded endpoints).
This implementation is limited to 32 devices which are allowed on
a single PCI bus.
From: Oleksandr Andrushchenko
Xen and/or Dom0 may have put values in PCI_COMMAND which they expect
to remain unaltered. PCI_COMMAND_SERR bit is a good example: while the
guest's view of this will want to be zero initially, the host having set
it to 1 may not easily be overwritten with 0, or else
From: Oleksandr Andrushchenko
At the moment, we always allocate an extra 16 slots for IO handlers
(see MAX_IO_HANDLER). So while adding IO trap handlers for the emulated
MSI-X registers we need to explicitly tell that we have additional IO
handlers, so those are accounted.
Signed-off-by:
From: Oleksandr Tyshchenko
Hi, all!
You can find previous discussion at [1].
1. This patch series is focusing on vPCI and adds support for non-identity
PCI BAR mappings which is required while passing through a PCI device to
a guest. The highlights are:
- Add relevant vpci register handlers
From: Oleksandr Andrushchenko
Reset the command register when assigning a PCI device to a guest:
according to the PCI spec the PCI_COMMAND register is typically all 0's
after reset, but this might not be true for the guest as it needs
to respect host's settings.
For that reason, do not write 0
From: Oleksandr Andrushchenko
There are range sets which should not be printed, so introduce a flag
which allows marking those as such. Implement relevant logic to skip
such entries while printing.
While at it also simplify the definition of the flags by directly
defining those without helpers.
From: Oleksandr Andrushchenko
When a PCI device gets assigned/de-assigned some work on vPCI side needs
to be done for that device. Introduce a pair of hooks so vPCI can handle
that.
Signed-off-by: Oleksandr Andrushchenko
---
Since v6:
- do not pass struct domain to
From: Oleksandr Andrushchenko
Add a stub for is_memory_hole which is required for PCI passthrough
on Arm.
Signed-off-by: Oleksandr Andrushchenko
---
OT: It looks like the discussion got stuck. As I understand this
patch is not immediately needed in the context of current series
as PCI
From: Oleksandr Andrushchenko
Add relevant vpci register handlers when assigning PCI device to a domain
and remove those when de-assigning. This allows having different
handlers for different domains, e.g. hwdom and other guests.
Emulate guest BAR register values: this allows creating a guest
From: Oleksandr Andrushchenko
Instead of handling a single range set, that contains all the memory
regions of all the BARs and ROM, have them per BAR.
As the range sets are now created when a PCI device is added and destroyed
when it is removed so make them named and accounted.
Note that
Currently the vPMU state from a parent isn't copied to VM forks. To enable the
vPMU state to be copied to a fork VM we export certain vPMU functions. First,
the vPMU context needs to be allocated for the fork if the parent has one. For
this we introduce vpmu->allocate_context, which has previously
Hi Daniel,
> -Original Message-
> Subject: [PATCH v1 00/18] Hyperlaunch
With the adjustments that I suggested in other messages, this patch builds and
boots for me on x86 (including a device tree with a domU). I will continue to
poke around and see if I discover any other rough edges.
On 7/19/22 05:32, Jan Beulich wrote:
> On 06.07.2022 23:04, Daniel P. Smith wrote:
>> --- a/xen/arch/Kconfig
>> +++ b/xen/arch/Kconfig
>> @@ -17,3 +17,15 @@ config NR_CPUS
>>For CPU cores which support Simultaneous Multi-Threading or similar
>>technologies, this the number of
flight 171681 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171681/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 171664
Tests which did not
On 7/15/22 15:16, Julien Grall wrote:
> Hi Daniel,
>
> On 06/07/2022 22:04, Daniel P. Smith wrote:
>> For x86 the number of allowable multiboot modules varies between the
>> different
>> entry points, non-efi boot, pvh boot, and efi boot. In the case of
>> both Arm and
>> x86 this value is
On Fri, Jul 15, 2022 at 04:25:49PM +0200, Juergen Gross wrote:
> Today PAT is usable only with MTRR being active, with some nasty tweaks
> to make PAT usable when running as Xen PV guest, which doesn't support
> MTRR.
>
> The reason for this coupling is, that both, PAT MSR changes and MTRR
>
flight 171685 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171685/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 7/14/2022 6:45 PM, Chuck Zmudzinski wrote:
> On 7/14/2022 6:33 PM, Chuck Zmudzinski wrote:
> > On 7/14/2022 1:17 PM, Chuck Zmudzinski wrote:
> > > On 7/5/22 6:57 AM, Thorsten Leemhuis wrote:
> > > > [CCing tglx, mingo, Boris and Juergen]
> > > >
> > > > On 04.07.22 14:26, Jan Beulich wrote:
> >
On 19/07/2022 14:52, Anthony Perard wrote:
> diff --git a/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h
> b/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h
> index 350b7bd309c0..67ee1899e9a8 100644
> --- a/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h
> +++ b/OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.h
> @@ -11,8 +11,9 @@
> #define
From: Anthony PERARD
The macro "xen_mb()" needs to be a full memory barrier, that is it
needs to also prevent stores from been reorder after loads which an
x86 CPU can do (as I understand from reading [1]). So this patch makes
use of "mfence" instruction.
Currently, there's a good chance that
On 06.07.2022 23:04, Daniel P. Smith wrote:
> --- /dev/null
> +++ b/xen/common/domain-builder/Kconfig
> @@ -0,0 +1,15 @@
> +
> +menu "Domain Builder Features"
> +
> +config BUILDER_FDT
> + bool "Domain builder device tree (UNSUPPORTED)" if UNSUPPORTED
> + select CORE_DEVICE_TREE
> +
On 06.07.2022 23:04, Daniel P. Smith wrote:
> --- a/xen/include/xen/bootinfo.h
> +++ b/xen/include/xen/bootinfo.h
> @@ -53,6 +53,17 @@ struct __packed boot_info {
>
> extern struct boot_info *boot_info;
>
> +static inline char *bootinfo_prepare_cmdline(struct boot_info *bi)
> +{
> +
On 06.07.2022 23:04, Daniel P. Smith wrote:
> This commit replaces the use of the multiboot v1 structures starting
> at __start_xen(). The majority of this commit is converting the fields
> being accessed for the startup calculations. While adapting the ucode
> boot module location logic, this
On 7/18/2022 7:32 AM, Chuck Zmudzinski wrote:
> On 7/17/2022 3:55 AM, Thorsten Leemhuis wrote:
> > Hi Juergen!
> >
> > On 15.07.22 16:25, Juergen Gross wrote:
> > > Today PAT can't be used without MTRR being available, unless MTRR is at
> > > least configured via CONFIG_MTRR and the system is
On 06.07.2022 23:04, Daniel P. Smith wrote:
> --- /dev/null
> +++ b/xen/arch/x86/include/asm/bootinfo.h
> @@ -0,0 +1,48 @@
> +#ifndef __ARCH_X86_BOOTINFO_H__
> +#define __ARCH_X86_BOOTINFO_H__
> +
> +/* unused for x86 */
> +struct arch_bootstring { };
> +
> +struct __packed arch_bootmodule {
>
Already ISE rev 044 added text to this effect; rev 045 further dropped
leftover earlier text indicating the contrary:
- ENQCMD requires the low 32 bits of the memory operand to be clear,
- ENDCMDS requires bits 20...30 of the memory operand to be clear.
Signed-off-by: Jan Beulich
---
I'm a
Since both kernel and user mode run in ring 3, they run in the same
"predictor mode". While the kernel could take care of this itself, doing
so would be yet another item distinguishing PV from native. Additionally
we're in a much better position to issue the barrier command, and we can
save a #GP
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Henry,
>
> Forwarded Message
> Subject: Ping²: [PATCH] x86: enable interrupts around dump_execstate()
>
> >On 11.01.2022 11:08, Jan Beulich wrote:
> >> On 16.12.2021 14:33, Jan Beulich wrote:
> >>> On 16.12.2021
On 19.07.2022 13:22, Andrew Cooper wrote:
> On 16/12/2021 13:33, Jan Beulich wrote:
>> On 16.12.2021 12:54, Andrew Cooper wrote:
>>> On 13/12/2021 15:12, Jan Beulich wrote:
show_hvm_stack() requires interrupts to be enabled to avoids triggering
the consistency check in check_lock() for
On 16/12/2021 13:33, Jan Beulich wrote:
> On 16.12.2021 12:54, Andrew Cooper wrote:
>> On 13/12/2021 15:12, Jan Beulich wrote:
>>> show_hvm_stack() requires interrupts to be enabled to avoids triggering
>>> the consistency check in check_lock() for the p2m lock. To do so in
>>>
Henry,
Forwarded Message
Subject: Ping²: [PATCH] x86: enable interrupts around dump_execstate()
Date: Tue, 5 Jul 2022 18:19:38 +0200
From: Jan Beulich
To: Andrew Cooper , Roger Pau Monné
CC: Wei Liu , xen-devel@lists.xenproject.org
>On 11.01.2022 11:08, Jan Beulich wrote:
flight 171680 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171680/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
flight 171678 xen-unstable real [real]
flight 171684 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171678/
http://logs.test-lab.xenproject.org/osstest/logs/171684/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 19.07.2022 12:32, Volodymyr Babchuk wrote:
> Jan Beulich writes:
>
>> On 18.07.2022 23:15, Volodymyr Babchuk wrote:
>>> Patch b4f211606011 ("vpci/msix: fix PBA accesses") introduced call to
>>> iounmap(), but not added corresponding include.
>>>
>>> Fixes: b4f211606011 ("vpci/msix: fix PBA
Hello Jan,
Jan Beulich writes:
> On 18.07.2022 23:15, Volodymyr Babchuk wrote:
>> Patch b4f211606011 ("vpci/msix: fix PBA accesses") introduced call to
>> iounmap(), but not added corresponding include.
>>
>> Fixes: b4f211606011 ("vpci/msix: fix PBA accesses")
>
> I don't think there's any
flight 171682 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171682/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 06.07.2022 23:04, Daniel P. Smith wrote:
> This refactors reusable code from Arm's bootfdt.c and device-tree.h that is
> general fdt handling code. The Kconfig parameter CORE_DEVICE_TREE is
> introduced for when the ability of parsing DTB files is needed by a capability
> such as hyperlaunch.
On 06.07.2022 23:04, Daniel P. Smith wrote:
> --- a/xen/arch/Kconfig
> +++ b/xen/arch/Kconfig
> @@ -17,3 +17,15 @@ config NR_CPUS
> For CPU cores which support Simultaneous Multi-Threading or similar
> technologies, this the number of logical threads which Xen will
>
> From: Roger Pau Monne
> Sent: Friday, July 1, 2022 9:17 PM
> @@ -4589,6 +4601,22 @@ void vmx_vmexit_handler(struct cpu_user_regs
> *regs)
> */
> break;
>
> +case EXIT_REASON_NOTIFY:
> +__vmread(EXIT_QUALIFICATION, _qualification);
> +
> +if (
Hi Jan,
On 19/07/2022 06:58, Jan Beulich wrote:
On 18.07.2022 18:28, Julien Grall wrote:
On 18/07/2022 17:12, Jan Beulich wrote:
On 27.05.2022 09:24, Juergen Gross wrote:
As you committed, I would be OK if this is addressed in a follow-up
series. But this *must* be addressed by the time 4.17
Hi Christopher,
> On 19 Jul 2022, at 05:34, Christopher Clark
> wrote:
>
> On Thu, Jul 14, 2022 at 3:10 AM Bertrand Marquis
> wrote:
>>
>> This patch series is a first attempt to check if we could use Yocto in
>> gitlab ci to build and run xen on qemu for arm, arm64 and x86.
>
> Hi
> From: Roger Pau Monne
> Sent: Friday, July 1, 2022 9:17 PM
>
> @@ -225,6 +225,9 @@ static inline void pi_clear_sn(struct pi_desc *pi_desc)
>
> /*
> * Interruption-information format
> + *
> + * Note INTR_INFO_NMI_UNBLOCKED_BY_IRET is also used with Exit
> Qualification
> + * field under
> From: Roger Pau Monné
> Sent: Monday, July 4, 2022 6:07 PM
>
> On Mon, Jul 04, 2022 at 11:27:37AM +0200, Jan Beulich wrote:
> > On 01.07.2022 15:16, Roger Pau Monne wrote:
> > > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > > @@ -4065,6 +4065,11 @@ void
> From: Roger Pau Monne
> Sent: Friday, July 1, 2022 9:17 PM
>
> @@ -4065,6 +4065,11 @@ void vmx_vmexit_handler(struct cpu_user_regs
> *regs)
>
> if ( unlikely(exit_reason & VMX_EXIT_REASONS_FAILED_VMENTRY) )
> return vmx_failed_vmentry(exit_reason, regs);
Add a blank line.
> +
flight 171676 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171676/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 171648
test-armhf-armhf-libvirt 16
On 19.07.2022 08:47, Dylanger Daly wrote:
> Yes ☹️, do you know if it's possible to obtain logs some other way for a
> system that doesn't have a COM port? console=vga exists but I can't seem to
> flip over to the vga "console" after I trigger the start of a VM
I'd focus on the booting issues
flight 171679 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171679/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f0064ac3afa28e1aa3b6b9c22c6cf422a4bb8771
baseline version:
ovmf
For guests in shadow mode the P2M table gets used only by software. The
only place where it matters whether superpages in the P2M can be dealt
with is sh_unshadow_for_p2m_change(): The table is never made accessible
to hardware for address translation, and the only checks of _PAGE_PSE in
P2M
In preparation for reactivating the presently dead 2M page path of the
function, also deal with the case of replacing an L1 page table all in
one go.
Signed-off-by: Jan Beulich
---
v2: Split from previous bigger patch.
--- a/xen/arch/x86/mm/shadow/hvm.c
+++ b/xen/arch/x86/mm/shadow/hvm.c
@@
Pull common checks out of the switch(). This includes extending a
_PAGE_PRESENT check to L1 as well, which presumably was deemed redundant
with p2m_is_valid() || p2m_is_grant(), but I think we are better off
being explicit in all cases. Note that for L2 (or higher) the grant
check isn't strictly
Replace a p2m_is_ram() check in the 2M case by an explicit _PAGE_PRESENT
one, to make more obvious that the subsequent l1e_get_mfn() actually
retrieves something that really is an MFN. It doesn't really matter
whether it's RAM, as the subsequent comparison with the original MFN is
going to lead to
Dom0 (being a VM itself) boots just perfectly, it's any other domU that
triggers the issue, I'm hoping I can somehow hook up gdb or something to Xen
somehow
Original Message
On Jul 19, 2022, 4:29 PM, Jan Beulich wrote:
> On 19.07.2022 01:04, Dylanger Daly wrote: > I'm having
I did notice this anomaly in the context of IOMMU side work.
1: shadow: slightly consolidate sh_unshadow_for_p2m_change() (part I)
2: shadow: slightly consolidate sh_unshadow_for_p2m_change() (part II)
3: shadow: slightly consolidate sh_unshadow_for_p2m_change() (part III)
4: P2M: allow 2M
Yes ☹️, do you know if it's possible to obtain logs some other way for a system
that doesn't have a COM port? console=vga exists but I can't seem to flip over
to the vga "console" after I trigger the start of a VM
Original Message
On Jul 19, 2022, 4:29 PM, Jan Beulich wrote:
On 19.07.2022 01:04, Dylanger Daly wrote:
> I'm having issues getting QubesOS running on my Lenovo Yoga Slim 7 ProX (AMD
> Ryzen 6800HS)
>
> Firstly in order to boot the device at all, I'm required to add
> `dom0_max_vcpus=1 dom0_vcpus_pin` to dom0's CMDLINE, this is similar to what
> I had to
On 18.07.2022 22:50, Andrew Cooper wrote:
> --- a/xen/arch/x86/hvm/vmx/entry.S
> +++ b/xen/arch/x86/hvm/vmx/entry.S
> @@ -33,13 +33,12 @@ ENTRY(vmx_asm_vmexit_handler)
> movb $1,VCPU_vmx_launched(%rbx)
> mov %rax,VCPU_hvm_guest_cr2(%rbx)
>
> -/*
Hi Volodymyr,
On 2022/7/19 5:15, Volodymyr Babchuk wrote:
From: Oleksandr Andrushchenko
if ( !use_msi )
return -EOPNOTSUPP;
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 938821e593..f93922acc8 100644
--- a/xen/drivers/passthrough/pci.c
On 18.07.2022 22:50, Andrew Cooper wrote:
> The logic was written this way out of an abundance of caution, but the reality
> is that AMD parts don't currently have the RAS-flushing side effect, and nor
> do they intend to gain it.
Nit: Looks like there's a stray (leftover from a re-write) "and"
On 18.07.2022 22:50, Andrew Cooper wrote:
> The RSB stuffing loop and retpoline thunks date from the very beginning, when
> halting speculation was a brand new field.
>
> These days, we've largely settled on int3 for halting speculation in
> non-architectural paths. It's a single byte, and is
On 18.07.2022 23:15, Volodymyr Babchuk wrote:
> Patch b4f211606011 ("vpci/msix: fix PBA accesses") introduced call to
> iounmap(), but not added corresponding include.
>
> Fixes: b4f211606011 ("vpci/msix: fix PBA accesses")
I don't think there's any active issue with the "missing" include:
On 18.07.2022 19:39, Julien Grall wrote:
> On 18/07/2022 12:02, Jan Beulich wrote:
>> On 18.07.2022 12:24, Julien Grall wrote:
>> 3)
>> unsigned int inc_order = min(MAX_ORDER, flsl(e - s) - 1);
>>
>> if ( s )
>> inc_order = min(inc_order, ffsl(s) - 1U);
>
> I like
91 matches
Mail list logo
