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 fi
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 e21b2039112eeba9a93fd
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 entrie
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
@@ -847
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 ne
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
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 superpa
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)
>
> -/* SPEC_CTRL_ENTRY_FROM_VMX
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" he
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 ful
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:
That's
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 th
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:
>>> In the past there have been spotted some shortcomings in the Xenstore
>>> interface, which should be repaired. Those are in detail:
>>>
>>> - Using driver domains for
flight 171674 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171674/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 171664
Tests which did not
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 Bertrand, thanks for posting this.
I'm still making my way through it, and should be able to spea
flight 171677 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171677/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e21b2039112eeba9a93fdd7b70329a07a79c8f0e
baseline version:
ovmf 586b4a104bfeae277ce16
flight 171672 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171672/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 171666
test-armhf-armhf-libvirt 16 save
Hi Julien,
> -Original Message-
> From: Julien Grall
> Subject: Re: [PATCH v2 0/4] tools/xenstore: add some new features to the
> documentation
>
> Hi Jan,
>
> On 18/07/2022 17:12, Jan Beulich wrote:
> > On 27.05.2022 09:24, Juergen Gross wrote:
> >>
> >> Changes in V2:
> >> - added new
flight 171675 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171675/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 586b4a104bfeae277ce16687f852c4f26c4a3b73
baseline version:
ovmf 792ebb6374f2b92e2c4b8
Hi All,
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 do previously -
https://xen.markmail.org/sea
On 18/07/2022 22:31, [email protected] wrote:
> I am trying to run Xen-4.16.1-4.fc36 on Fedora 36 on a brand new Lenovo
> ThinkStation p620, but I keep getting the following error booting the
> Xen kernel.
>
> Panic on CPU 0:
> FATAL TRAP: vec 7, #NM[]
>
> Version info:
> Name : xen
>
flight 171670 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171670/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair broken
test-amd64-amd64-libvirt-pair 7 host-in
flight 171673 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171673/
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 1
From: Oleksandr Andrushchenko
vPCI MMIO handlers are accessing pdevs without protecting this access
with pcidevs_{lock|unlock}. This is not a problem as of now as these
are only used by Dom0. But, towards vPCI is used also for guests, we need
to properly protect pdev and pdev->vpci from being rem
From: Oleksandr Andrushchenko
Currently pcidevs lock is a global recursive spinlock which is fine for
the existing use cases. It is used to both protect pdev instances
themselves from being removed while in use and to make sure the update
of the relevant pdev properties is synchronized.
Moving t
Patch b4f211606011 ("vpci/msix: fix PBA accesses") introduced call to
iounmap(), but not added corresponding include.
Fixes: b4f211606011 ("vpci/msix: fix PBA accesses")
Signed-off-by: Volodymyr Babchuk
---
xen/drivers/vpci/vpci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/drivers/
From: Oleksandr Andrushchenko
A guest would be able to read and write those registers which are not
emulated and have no respective vPCI handlers, so it will be possible
for it to access the hardware directly.
In order to prevent a guest from reads and writes from/to the unhandled
registers make
Hello all,
While Oleksandr Andrushchenko is busy with more important matters, I
want to continue his work on preparing different Xen subsystems to
support PCI on ARM platform.
This patch series are mostly focused on next take of PCI locking
rework. It introduces reentrant read/write locking mecha
This is a continuation of the observation from:
e9b8d31981f1 ("x86/spec-ctrl: Rework SPEC_CTRL_ENTRY_FROM_INTR_IST")
53a570b28569 ("x86/spec-ctrl: Support IBPB-on-entry")
With %rdx known to be zero and not clobbered on the early entry path, we don't
need to re-zero it every time want to write
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.
This removes one WRMSR from the VMExit path by default on Zen2 systems.
Fixes: 614cec7d79d7 ("x86/svm: VMEntry/Exi
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 fully serialising - a
requirement for delivering #BP if
Fixes accumulated during XSA-407 which weren't security worthy in and of
themselves.
Andrew Cooper (3):
x86/spec-ctrl: Consistently halt speculation using int3
x86/spec-ctrl: Make svm_vmexit_spec_ctrl conditional
x86/spec-ctrl: Shrink further entry paths due to %rdx being 0
xen/arch/x86/hv
flight 171671 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171671/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 792ebb6374f2b92e2c4b84f5b8d151a129ed81cc
baseline version:
ovmf fc4a132c0e9d108d30115
flight 171669 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171669/
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 1
[ Upstream commit 166d3863231667c4f64dee72b77d1102cdfad11f ]
The error paths of gntdev_mmap() can call unmap_grant_pages() even
though not all of the pages have been successfully mapped. This will
trigger the WARN_ON()s in __unmap_grant_pages_done(). The number of
warnings can be very large; I h
[ Upstream commit 166d3863231667c4f64dee72b77d1102cdfad11f ]
The error paths of gntdev_mmap() can call unmap_grant_pages() even
though not all of the pages have been successfully mapped. This will
trigger the WARN_ON()s in __unmap_grant_pages_done(). The number of
warnings can be very large; I h
[ Upstream commit 166d3863231667c4f64dee72b77d1102cdfad11f ]
The error paths of gntdev_mmap() can call unmap_grant_pages() even
though not all of the pages have been successfully mapped. This will
trigger the WARN_ON()s in __unmap_grant_pages_done(). The number of
warnings can be very large; I h
[ Upstream commit 166d3863231667c4f64dee72b77d1102cdfad11f ]
The error paths of gntdev_mmap() can call unmap_grant_pages() even
though not all of the pages have been successfully mapped. This will
trigger the WARN_ON()s in __unmap_grant_pages_done(). The number of
warnings can be very large; I h
[ Upstream commit 166d3863231667c4f64dee72b77d1102cdfad11f ]
The error paths of gntdev_mmap() can call unmap_grant_pages() even
though not all of the pages have been successfully mapped. This will
trigger the WARN_ON()s in __unmap_grant_pages_done(). The number of
warnings can be very large; I h
This series backports upstream commit 166d3863231667c4f64dee72b77d1102cdfad11f
to all supported stable kernel trees.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
Hi Jan,
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 this idea!
No compilation issues to expect here, af
Hi Jan,
On 18/07/2022 17:12, Jan Beulich wrote:
On 27.05.2022 09:24, Juergen Gross wrote:
In the past there have been spotted some shortcomings in the Xenstore
interface, which should be repaired. Those are in detail:
- Using driver domains for large number of domains needs per domain
Xenst
On 27.05.2022 09:24, Juergen Gross wrote:
> In the past there have been spotted some shortcomings in the Xenstore
> interface, which should be repaired. Those are in detail:
>
> - Using driver domains for large number of domains needs per domain
> Xenstore quota [1]. The feedback sent was rather
Hello SeongJae,
Thanks for the efforts.
I've tested backend patches(1,2) on my custom 5.10 kernel (since I
can't test on vanilla) and it works for me.
Best regards,
Andrii
On Sat, Jul 16, 2022 at 1:51 AM SeongJae Park wrote:
>
> Introduction of 'feature_persistent' made two bugs. First one is
On 14/07/2022 08:53, Jan Beulich wrote:
> While a number of issues we previously had with pre-release gcc12 were
> fixed in the final release, we continue to have one issue (with multiple
> instances) when doing release builds (i.e. at higher optimization
> levels): The compiler takes issue with su
On 13/07/2022 08:52, Jan Beulich wrote:
> There are command line controls for this and the default also isn't "always
> enable when hardware supports it", which logging should take into account.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On 13/07/2022 07:51, Jan Beulich wrote:
> This eases recognizing that something odd is going on.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -845,6 +845,9 @@ void fatal_trap(const struct cpu_user_re
> msecs = 10;
>
flight 171668 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171668/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fc4a132c0e9d108d30115cb8729f8fcd5564b855
baseline version:
ovmf 039bdb4d3e96f9c9264ab
On 18.07.2022 14:54, Marek Marczykowski-Górecki wrote:
> On Thu, Jul 14, 2022 at 02:06:07PM +0200, Jan Beulich wrote:
>> On 06.07.2022 17:32, Marek Marczykowski-Górecki wrote:
>>> That's possible, because the capability was designed specifically to
>>> allow separate driver handle it, in parallel t
On 18.07.2022 14:48, Marek Marczykowski-Górecki wrote:
> On Wed, Jul 13, 2022 at 11:39:07AM +0200, Jan Beulich wrote:
>> On 06.07.2022 17:32, Marek Marczykowski-Górecki wrote:
>>> --- a/xen/drivers/char/console.c
>>> +++ b/xen/drivers/char/console.c
>>> @@ -113,7 +113,9 @@ static char *__read_mostl
On Mon, Jul 18, 2022 at 10:18 AM Jan Beulich wrote:
>
> On 18.07.2022 16:05, Jason Andryuk wrote:
> > Let the hardware domain know about the hardware it is running on. This
> > allows a linux Dom0 to know that it has the appropriate microcode via
> > FB_CLEAR. /sys/devices/system/cpu/vulnerabili
On 18.07.2022 16:05, Jason Andryuk wrote:
> Let the hardware domain know about the hardware it is running on. This
> allows a linux Dom0 to know that it has the appropriate microcode via
> FB_CLEAR. /sys/devices/system/cpu/vulnerabilities/mmio_stale_data
> changes from:
> "Vulnerable: Clear CPU b
On 18.07.2022 14:07, Andrew Cooper wrote:
> On 18/07/2022 10:49, Jan Beulich wrote:
>> On 18.07.2022 11:31, Andrew Cooper wrote:
>>> On 18/07/2022 10:11, Jan Beulich wrote:
On 15.07.2022 15:26, Andrew Cooper wrote:
> --- a/xen/tools/check-endbr.sh
> +++ b/xen/tools/check-endbr.sh
>
Hi Jan,
On 18/07/2022 09:47, Jan Beulich wrote:
On 16.07.2022 16:38, Julien Grall wrote:
On 04/07/2022 13:35, Bertrand Marquis wrote:
On 24 Jun 2022, at 10:11, Julien Grall wrote:
From: Julien Grall
Both destroy_xen_mappings() and modify_xen_mappings() will take in
parameter a range [start
Let the hardware domain know about the hardware it is running on. This
allows a linux Dom0 to know that it has the appropriate microcode via
FB_CLEAR. /sys/devices/system/cpu/vulnerabilities/mmio_stale_data
changes from:
"Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state
unkno
On 7/18/22 4:56 AM, Andrew Cooper wrote:
On 15/07/2022 14:10, Boris Ostrovsky wrote:
On 7/15/22 5:50 AM, Andrew Cooper wrote:
On 15/07/2022 09:18, Jane Malalane wrote:
On 14/07/2022 00:27, Boris Ostrovsky wrote:
xen_hvm_smp_init();
WARN_ON(xen_cpuhp_setup(xen_cpu_up_prepare_
Hi Daniel,
> -Original Message-
> Subject: [PATCH v1 10/18] x86: introduce the domain builder
>
> This commit introduces the domain builder configuration FDT parser along
> with the domain builder core for domain creation. To enable domain builder
> to be a cross architecture internal API
Hi Daniel,
I hope outlook gets this reply right.
> -Original Message-
> Subject: [PATCH v1 04/18] x86: refactor entrypoints to new boot info
> diff --git a/xen/arch/x86/guest/xen/pvh-boot.c
> b/xen/arch/x86/guest/xen/pvh-boot.c
> index 834b1ad16b..28cf5df0a3 100644
> --- a/xen/arch/x86/g
Hi Daniel,
> -Original Message-
> Subject: [PATCH v1 07/18] docs: update hyperlaunch device tree
> documentation
> diff --git a/docs/designs/launch/hyperlaunch-devicetree.rst
> b/docs/designs/launch/hyperlaunch-devicetree.rst
> index b49c98cfbd..ae1a786d0b 100644
> --- a/docs/designs/lau
Hi Andrew,
Thank you very much for your detailed reply, that make things
a lot clearer. I did have a few follow up questions.
> gnttab v2 is horribly more complicated.
With v2, do the high level behaviours change much from
what you have outlined here? Do you expect in the long term
for v2 t
On 7/17/22 1:20 AM, Juergen Gross wrote:
What about filling the complete hypercall page just with "int 3" or "ud2"?
Any try to do a hypercall before the hypercall page has been initialized
is a bug anyway. What good can come from calling a function which will
return a basically random value i
On Mon, Jul 11, 2022 at 06:05:37PM +0200, Jan Beulich wrote:
> With debug info retained, xen.efi can be quite large. Unlike for xen.gz
> there's no intermediate step (mkelf32 there) involved which would strip
> debug info kind of as a side effect. While the installing of xen.efi on
> the EFI partit
On Thu, Jul 14, 2022 at 01:51:06PM +0200, Jan Beulich wrote:
> On 06.07.2022 17:32, Marek Marczykowski-Górecki wrote:
> > The important part is to include those buffers in IOMMU page table
> > relevant for the USB controller. Otherwise, DbC will stop working as
> > soon as IOMMU is enabled, regardl
On Tue, Jul 12, 2022 at 04:08:12PM +0200, Jan Beulich wrote:
> Move the "credit expired" loop exit to the middle of the loop,
> immediately after "return true". This way having reached the goal on the
> last iteration would be reported as success to the caller, rather than
> as "timed out".
>
> Si
On Thu, Jul 14, 2022 at 02:06:07PM +0200, Jan Beulich wrote:
> On 06.07.2022 17:32, Marek Marczykowski-Górecki wrote:
> > That's possible, because the capability was designed specifically to
> > allow separate driver handle it, in parallel to unmodified xhci driver
> > (separate set of registers, p
On Wed, Jul 13, 2022 at 11:39:07AM +0200, Jan Beulich wrote:
> On 06.07.2022 17:32, Marek Marczykowski-Górecki wrote:
> > Previously only one serial console was supported at the same time. Using
> > console=com1,dbgp,vga silently ignored all but last serial console (in
> > this case: only dbgp and
On Fri, Jul 15, 2022 at 04:25:47PM +0200, Juergen Gross wrote:
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 736262a76a12..e43322f8a4ef 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
I guess the move's ok but not into cpu/commo
On 7/18/2022 7:39 AM, Jan Beulich wrote:
> On 18.07.2022 13:31, Chuck Zmudzinski wrote:
> > On 7/18/2022 2:07 AM, Jan Beulich wrote:
> >> On 15.07.2022 21:53, Chuck Zmudzinski wrote:
> >>> Two things I see here in my efforts to get a patch to fix this regression:
> >>>
> >>> 1. Does Xen have plans
On 18/07/2022 10:49, Jan Beulich wrote:
> On 18.07.2022 11:31, Andrew Cooper wrote:
>> On 18/07/2022 10:11, Jan Beulich wrote:
>>> On 15.07.2022 15:26, Andrew Cooper wrote:
--- a/xen/tools/check-endbr.sh
+++ b/xen/tools/check-endbr.sh
@@ -61,19 +61,36 @@ ${OBJDUMP} -j .text $1 -d -w
On 7/18/2022 7:39 AM, Jan Beulich wrote:
> On 18.07.2022 13:31, Chuck Zmudzinski wrote:
> > On 7/18/2022 2:07 AM, Jan Beulich wrote:
> >> On 15.07.2022 21:53, Chuck Zmudzinski wrote:
> >>> Two things I see here in my efforts to get a patch to fix this regression:
> >>>
> >>> 1. Does Xen have plans
On 18.07.2022 13:35, Marek Marczykowski-Górecki wrote:
> On Thu, Jul 14, 2022 at 12:22:36PM +0200, Jan Beulich wrote:
>> On 06.07.2022 17:32, Marek Marczykowski-Górecki wrote:
>>> --- a/xen/drivers/passthrough/amd/iommu_acpi.c
>>> +++ b/xen/drivers/passthrough/amd/iommu_acpi.c
>>> @@ -1078,6 +1078,
On 18.07.2022 13:31, Chuck Zmudzinski wrote:
> On 7/18/2022 2:07 AM, Jan Beulich wrote:
>> On 15.07.2022 21:53, Chuck Zmudzinski wrote:
>>> Two things I see here in my efforts to get a patch to fix this regression:
>>>
>>> 1. Does Xen have plans to give Linux running in Dom0 write-access to the
>>>
On Thu, Jul 14, 2022 at 12:22:36PM +0200, Jan Beulich wrote:
> On 06.07.2022 17:32, Marek Marczykowski-Górecki wrote:
> > --- a/xen/drivers/passthrough/amd/iommu_acpi.c
> > +++ b/xen/drivers/passthrough/amd/iommu_acpi.c
> > @@ -1078,6 +1078,20 @@ static inline bool_t is_ivmd_block(u8 type)
> >
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 running as Xen PV
> > guest. In this case PAT is automatically
On 7/18/2022 2:07 AM, Jan Beulich wrote:
> On 15.07.2022 21:53, Chuck Zmudzinski wrote:
> > Two things I see here in my efforts to get a patch to fix this regression:
> >
> > 1. Does Xen have plans to give Linux running in Dom0 write-access to the
> > PAT MSR?
>
> No, as this is not technically fe
On 18/07/2022 12:11, Jan Beulich wrote:
> On 18.07.2022 09:18, Andrew Cooper wrote:
>> This started out as patch 2 for a different task, and quickly identified some
>> technical debt, long overdue for cleaning up.
>>
>> Andrew Cooper (5):
>> xen/wait: Drop vestigial remnants of TRAP_regs_partial
On 18/07/2022 11:48, Jan Beulich wrote:
> On 18.07.2022 09:18, Andrew Cooper wrote:
>> With the waitqueue logic updated to not use an absolute stack pointer
>> reference, the vCPU can safely be resumed anywhere.
>>
>> Remove VCPU_AFFINITY_WAIT completely, getting rid of two domain crashes,
> I unde
On 18.07.2022 13:03, Marek Marczykowski-Górecki wrote:
> On Thu, Jul 14, 2022 at 12:17:53PM +0200, Jan Beulich wrote:
>> On 06.07.2022 17:32, Marek Marczykowski-Górecki wrote:
>>> +};
>>> +static unsigned int __initdata nr_extra_reserved_ranges;
>>> +static struct extra_reserved_range __initdata
>
On 18.07.2022 12:53, Marek Marczykowski-Górecki wrote:
> On Thu, Jul 14, 2022 at 12:17:53PM +0200, Jan Beulich wrote:
>> On 06.07.2022 17:32, Marek Marczykowski-Górecki wrote:
>>> --- a/xen/drivers/passthrough/iommu.c
>>> +++ b/xen/drivers/passthrough/iommu.c
>>> @@ -651,6 +651,46 @@ bool_t iommu_h
On 18.07.2022 09:18, Andrew Cooper wrote:
> This started out as patch 2 for a different task, and quickly identified some
> technical debt, long overdue for cleaning up.
>
> Andrew Cooper (5):
> xen/wait: Drop vestigial remnants of TRAP_regs_partial
> xen/wait: Extend the description of how th
On Thu, Jul 14, 2022 at 12:17:53PM +0200, Jan Beulich wrote:
> On 06.07.2022 17:32, Marek Marczykowski-Górecki wrote:
> > +};
> > +static unsigned int __initdata nr_extra_reserved_ranges;
> > +static struct extra_reserved_range __initdata
> > extra_reserved_ranges[MAX_EXTRA_RESERVED_RANGES];
>
>
On 18.07.2022 12:24, Julien Grall wrote:
> Hi Jan,
>
> On 18/07/2022 10:43, Jan Beulich wrote:
>> On 15.07.2022 19:03, Julien Grall wrote:
>>> @@ -1806,8 +1806,22 @@ static void _init_heap_pages(const struct page_info
>>> *pg,
>>>
>>> while ( s < e )
>>> {
>>> -free_heap_pa
On 18.07.2022 12:08, Julien Grall wrote:
> On 18/07/2022 10:31, Jan Beulich wrote:
>> On 15.07.2022 19:03, Julien Grall wrote:
>>> --- a/xen/common/page_alloc.c
>>> +++ b/xen/common/page_alloc.c
>>> @@ -1778,16 +1778,44 @@ int query_page_offline(mfn_t mfn, uint32_t *status)
>>> }
>>>
>>> /*
On 18.07.2022 12:45, Marek Marczykowski-Górecki wrote:
> On Tue, Jul 12, 2022 at 05:59:51PM +0200, Jan Beulich wrote:
>> On 06.07.2022 17:32, Marek Marczykowski-Górecki wrote:
>>> +static bool __init xue_init_xhc(struct xue *xue)
>>> +{
>>> +uint32_t bar0;
>>> +uint64_t bar1;
>>> +uint6
On Thu, Jul 14, 2022 at 12:17:53PM +0200, Jan Beulich wrote:
> On 06.07.2022 17:32, Marek Marczykowski-Górecki wrote:
> > --- a/xen/drivers/passthrough/iommu.c
> > +++ b/xen/drivers/passthrough/iommu.c
> > @@ -651,6 +651,46 @@ bool_t iommu_has_feature(struct domain *d, enum
> > iommu_feature featu
On 18.07.2022 12:41, Andrew Cooper wrote:
> On 18/07/2022 11:29, Jan Beulich wrote:
>> On 18.07.2022 09:18, Andrew Cooper wrote:
>>> -"mov %%rsp,%%rsi;"
>>> +
>>> +"mov %%ecx, %%eax;"
>>> +"mov %%rsp, %%rsi;" /* Copy from the stack, into wqv->stack */
>>>
>>> /* c
On 18.07.2022 12:11, Andrew Cooper wrote:
> On 18/07/2022 11:00, Jan Beulich wrote:
>> On 18.07.2022 09:18, Andrew Cooper wrote:
>>> @@ -199,9 +211,18 @@ void check_wakeup_from_wait(void)
>>> }
>>>
>>> /*
>>> - * Hand-rolled longjmp(). Returns to __prepare_to_wait(), and lands
>>>
On 18.07.2022 09:18, Andrew Cooper wrote:
> With the waitqueue logic updated to not use an absolute stack pointer
> reference, the vCPU can safely be resumed anywhere.
>
> Remove VCPU_AFFINITY_WAIT completely, getting rid of two domain crashes,
I understand you mean two domain_crash() invocations
On Tue, Jul 12, 2022 at 05:59:51PM +0200, Jan Beulich wrote:
> On 06.07.2022 17:32, Marek Marczykowski-Górecki wrote:
> > --- a/docs/misc/xen-command-line.pandoc
> > +++ b/docs/misc/xen-command-line.pandoc
> > @@ -721,10 +721,15 @@ Available alternatives, with their meaning, are:
> >
> > ### dbg
On 18/07/2022 11:29, Jan Beulich wrote:
> On 18.07.2022 09:18, Andrew Cooper wrote:
>> -"mov %%rsp,%%rsi;"
>> +
>> +"mov %%ecx, %%eax;"
>> +"mov %%rsp, %%rsi;" /* Copy from the stack, into wqv->stack */
>>
>> /* check_wakeup_from_wait() longjmp()'s to this point.
On 18.07.2022 09:18, Andrew Cooper wrote:
> @@ -121,11 +121,11 @@ void wake_up_all(struct waitqueue_head *wq)
>
> static void __prepare_to_wait(struct waitqueue_vcpu *wqv)
> {
> -struct cpu_info *cpu_info = get_cpu_info();
> struct vcpu *curr = current;
> unsigned long dummy;
> +
Hi Jan,
On 18/07/2022 10:43, Jan Beulich wrote:
On 15.07.2022 19:03, Julien Grall wrote:
@@ -1806,8 +1806,22 @@ static void _init_heap_pages(const struct page_info *pg,
while ( s < e )
{
-free_heap_pages(mfn_to_page(_mfn(s)), 0, need_scrub);
-s += 1UL;
+/
On 18/07/2022 11:00, Jan Beulich wrote:
> On 18.07.2022 09:18, Andrew Cooper wrote:
>> @@ -199,9 +211,18 @@ void check_wakeup_from_wait(void)
>> }
>>
>> /*
>> - * Hand-rolled longjmp(). Returns to __prepare_to_wait(), and lands on
>> a
>> - * `rep movs` instruction. All other
Hi Jan,
On 18/07/2022 10:31, Jan Beulich wrote:
On 15.07.2022 19:03, Julien Grall wrote:
From: Julien Grall
At the moment, init_heap_pages() will call free_heap_pages() page
by page. To reduce the time to initialize the heap, we will want
to provide multiple pages at the same time.
init_heap
On 18/07/2022 09:18, Wei Chen wrote:
static void init_heap_pages(
struct page_info *pg, unsigned long nr_pages)
{
unsigned long i;
- bool idle_scrub = false;
+ bool need_scrub = scrub_debug;
You have changed idle_scrub to need_scrub, but haven't mentioned this
in commi
On 18.07.2022 09:18, Andrew Cooper wrote:
> --- a/xen/common/wait.c
> +++ b/xen/common/wait.c
> @@ -151,13 +151,12 @@ static void __prepare_to_wait(struct waitqueue_vcpu
> *wqv)
> * copies in from wqv->stack over the active stack.
> */
> asm volatile (
> -"push %%rax; push
1 - 100 of 129 matches
Mail list logo
