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
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
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
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
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
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
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 -
On 18/07/2022 22:31, ch...@dalessio.org 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
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
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
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
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
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
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:
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
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
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
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
[ 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
[ 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
[ 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
[ 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
[ 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
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,
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
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
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
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
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
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
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
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.
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
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
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
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();
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
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
> ---
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
> ---
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
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
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
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,
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".
>
>
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,
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
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
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
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
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
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
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 )
>>> {
>>> -
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;
>>> +
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
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 */
>>>
>>> /*
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()
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:
> >
> > ###
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
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.
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
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;
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 GPRs are restored from the stack,
> so
> - *
On 18.07.2022 09:18, Andrew Cooper wrote:
> The preservation of entry_vector was introduced with ecf9846a6a20 ("x86:
> save/restore only partial register state where possible") where
> TRAP_regs_partial was introduced, but missed from f9eb74789af7 ("x86/entry:
> Remove support for partial
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 | grep ' endbr64 *$' |
>>> cut -f 1 -d ':'
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;
> +/*
> + * For s == 0, we simply
On 18/07/2022 10:11, Jan Beulich wrote:
> On 15.07.2022 15:26, Andrew Cooper wrote:
>> While Xen's current VMA means it works, the mawk fix (i.e. using $((0xN)) in
>> the shell) isn't portable in 32bit shells. See the code comment for the fix.
>>
>> The fix found a second latent bug. Recombining
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_pages() is now split in two parts:
>
From: Oleksandr Tyshchenko
Re-generate goland bindings to reflect changes to libxl_types.idl
from the following commit:
54d8f27d0477 tools/libxl: report trusted backend status to frontends
Signed-off-by: Oleksandr Tyshchenko
---
tools/golang/xenlight/helpers.gen.go | 12
flight 171666 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171666/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-examine-bios 6 xen-install fail in 171663 pass in 171666
On 15.07.2022 15:26, Andrew Cooper wrote:
> While Xen's current VMA means it works, the mawk fix (i.e. using $((0xN)) in
> the shell) isn't portable in 32bit shells. See the code comment for the fix.
>
> The fix found a second latent bug. Recombining $vma_hi/lo should have used
> printf
Hello,
It has been raised on the freebsd-xen mailing list [0] that the socket
queue length for the xenstored local domain socket is set to 1, which
can cause concurrent executions of xl commands to fail.
I see in xenstored implementation (xenstored_core.c init_sockets())
that the call to
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_hvm,
>
On 16.07.2022 16:56, Oleksandr Tyshchenko wrote:
> 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 a grant table page is
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, end[. Both end should be
Hi Julien,
On 2022/7/16 1:03, Julien Grall wrote:
From: Hongyan Xia
The idea is to split the range into multiple aligned power-of-2 regions
which only needs to call free_heap_pages() once each. We check the least
significant set bit of the start address and use its bit index as the
order of
On 18.07.2022 09:43, Wei Chen wrote:
> On 2022/7/11 22:32, Jan Beulich wrote:
>> the other day I wanted to look at the basic structure of xen.efi. First
>> I used my own dumping tool, which didn't work. Then I used objdump,
>> which appeared to work. I decided that I should look into what they do
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2022年7月18日 16:10
> To: Wei Chen
> Cc: nd ; Andrew Cooper ; George
> Dunlap ; Stefano Stabellini
> ; Wei Liu ; Roger Pau Monné
> ; xen-devel@lists.xenproject.org; Julien Grall
>
> Subject: Re: [PATCH v2 9/9] xen: introduce a
1 - 100 of 116 matches
Mail list logo
