On 28.10.21 01:24, Stefano Stabellini wrote:
On Wed, 27 Oct 2021, Stefano Stabellini wrote:
On Wed, 27 Oct 2021, Juergen Gross wrote:
On 26.10.21 02:54, Stefano Stabellini wrote:
On Mon, 25 Oct 2021, Juergen Gross wrote:
On 22.10.21 21:41, Stefano Stabellini wrote:
+Juergen
On Fri, 22 Oct 2
The pvops function for Xen PV guests handling the interrupt flag are
much more complex than needed.
With the supported Xen hypervisor versions they can be simplified a
lot, especially by removing the need for disabling preemption.
Juergen Gross (2):
x86/xen: remove xen_have_vcpu_info_placement
The initial pvops functions handling irq flags will only ever be called
before interrupts are being enabled.
So switch them to be dummy functions:
- xen_save_fl() can always return 0
- xen_irq_disable() is a nop
- xen_irq_enable() can BUG()
Add some generic paravirt functions for that purpose.
S
The flag xen_have_vcpu_info_placement was needed to support Xen
hypervisors older than version 3.4, which didn't support the
VCPUOP_register_vcpu_info hypercall. Today the Linux kernel requires
at least Xen 4.0 to be able to run, so xen_have_vcpu_info_placement
can be dropped (in theory the flag wa
On Wed, Oct 27, 2021 at 09:07:13PM +0100, Andrew Cooper wrote:
> GCC master (nearly version 12) complains:
>
> hvm.c: In function 'hvm_gsi_eoi':
> hvm.c:905:10: error: the comparison will always evaluate as 'true' for the
> address of 'dpci' will never be NULL [-Werror=address]
> 905 |
On 27.10.21 23:16, Dmitry Osipenko wrote:
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new power-off API.
Signed-of
Some cleanups, mostly related to no longer supporting 32-bit PV mode.
Juergen Gross (4):
x86/xen: remove 32-bit pv leftovers
xen: allow pv-only hypercalls only with CONFIG_XEN_PV
xen: remove highmem remnants
x86/xen: remove 32-bit awareness from startup_xen
arch/arm/xen/enlighten.c
startup_xen is still 32-bit aware, even if no longer needed.
Replace the register macros by the 64-bit register names for making
it more readable.
Signed-off-by: Juergen Gross
---
arch/x86/xen/xen-head.S | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/x
There are some remaining 32-bit pv-guest support leftovers in the Xen
hypercall interface. Remove them.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/xen/hypercall.h | 40 +++-
drivers/xen/mem-reservation.c| 27 +++
2 files changed, 19 inse
Put the definitions of the hypercalls usable only by pv guests inside
CONFIG_XEN_PV sections.
On Arm two dummy functions related to pv hypercalls can be removed.
While at it remove the no longer supported tmem hypercall definition.
Signed-off-by: Juergen Gross
---
arch/arm/xen/enlighten.c
There are some references to highmem left in Xen pv specific code which
can be removed.
Signed-off-by: Juergen Gross
---
arch/x86/xen/enlighten_pv.c | 7 ---
arch/x86/xen/mmu_pv.c | 1 -
2 files changed, 8 deletions(-)
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_
On Wed, Oct 27, 2021 at 02:43:46PM -0700, Stefano Stabellini wrote:
> On Wed, 27 Oct 2021, Anthony PERARD wrote:
> > > But we do have a severe problem at the moment with external sources: our
> > > "git clones" keep failing during the build on x86. That is definitely
> > > something worth improving
On Wed, Oct 27, 2021 at 11:18 PM Dmitry Osipenko wrote:
>
> SoC platforms often have multiple options of how to perform system's
> power-off and restart operations. Meanwhile today's kernel is limited to
> a single option. Add combined power-off+restart handler call chain API,
> which is inspired
On Wed, Oct 27, 2021 at 11:18 PM Dmitry Osipenko wrote:
>
> SoC platforms often have multiple options of how to perform system's
> power-off and restart operations. Meanwhile today's kernel is limited to
> a single option. Add combined power-off+restart handler call chain API,
> which is inspired
Introduce a new domain create field so that toolstack can specify the
maximum grant table version usable by the domain. This is plumbed into
xl and settable by the user as max_grant_version.
Previously this was only settable on a per host basis using the
gnttab command line option.
Note the versi
Hi, all!
While working on PCI passthrough on Arm I stepped onto a crash
with the following call chain:
pci_physdev_op
pci_add_device
init_bars -> modify_bars -> defer_map -> raise_softirq(SCHEDULE_SOFTIRQ)
iommu_add_device <- FAILS
vpci_remove_device -> xfree(pdev->vpci)
Then:
le
Hi Stefano,
First apologies for sending the previous e-mails in HTML (thanks for
pointing that out!).
On 28/10/2021 01:20, Stefano Stabellini wrote:
On Thu, 28 Oct 2021, Julien Grall wrote:
On Thu, 28 Oct 2021, 00:14 Stefano Stabellini, wrote:
On Wed, 27 Oct 2021, Julien Grall wrote:
On Thu, Oct 28, 2021 at 10:04:20AM +, Oleksandr Andrushchenko wrote:
> Hi, all!
>
> While working on PCI passthrough on Arm I stepped onto a crash
> with the following call chain:
>
> pci_physdev_op
> pci_add_device
> init_bars -> modify_bars -> defer_map ->
> raise_softirq(SCHEDUL
On 28.10.21 13:17, Roger Pau Monné wrote:
> On Thu, Oct 28, 2021 at 10:04:20AM +, Oleksandr Andrushchenko wrote:
>> Hi, all!
>>
>> While working on PCI passthrough on Arm I stepped onto a crash
>> with the following call chain:
>>
>> pci_physdev_op
>> pci_add_device
>> init_bars -
flight 165922 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165922/
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
On Thu, Oct 28, 2021 at 10:25:28AM +, Oleksandr Andrushchenko wrote:
>
>
> On 28.10.21 13:17, Roger Pau Monné wrote:
> > On Thu, Oct 28, 2021 at 10:04:20AM +, Oleksandr Andrushchenko wrote:
> >> Hi, all!
> >>
> >> While working on PCI passthrough on Arm I stepped onto a crash
> >> with th
On 28.10.21 13:30, Roger Pau Monné wrote:
> On Thu, Oct 28, 2021 at 10:25:28AM +, Oleksandr Andrushchenko wrote:
>>
>> On 28.10.21 13:17, Roger Pau Monné wrote:
>>> On Thu, Oct 28, 2021 at 10:04:20AM +, Oleksandr Andrushchenko wrote:
Hi, all!
While working on PCI passthroug
Hi Stefano,
On 28/10/2021 00:57, Stefano Stabellini wrote:
On Wed, 27 Oct 2021, Julien Grall wrote:
Hi Oleksandr,
On 27/10/2021 09:37, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
If a PCI host bridge device is present in the device tree, but is
disabled, then its PCI host b
When running as PVH or HVM guest with actual memory < max memory the
hypervisor is using "populate on demand" in order to allow the guest
to balloon down from its maximum memory size. For this to work
correctly the guest must not touch more memory pages than its target
memory size as otherwise the
On Thu, Oct 28, 2021 at 12:16:33AM +0300, Dmitry Osipenko wrote:
> Add atomic/blocking_notifier_has_unique_priority() helpers which return
> true if given handler has unique priority.
...
> +/**
> + * atomic_notifier_has_unique_priority - Checks whether notifier's
> priority is unique
> + *
Hi, Julien!
[snip]
On 28.10.21 13:48, Julien Grall wrote:
> Hi Stefano,
>
> Looking at linux/arch/arm64/boot/dts/, there are a few Device-Tree that
> contain the property "linux,pci-domain". All of them seems to also add it for
> disabled hostbridges.
>
> However, I am under the impression that
On 28/10/2021 12:01, Oleksandr Andrushchenko wrote:
Hi, Julien!
[snip]
On 28.10.21 13:48, Julien Grall wrote:
Hi Stefano,
Looking at linux/arch/arm64/boot/dts/, there are a few Device-Tree that contain the
property "linux,pci-domain". All of them seems to also add it for disabled
hostbrid
On 28.10.21 14:03, Julien Grall wrote:
>
>
> On 28/10/2021 12:01, Oleksandr Andrushchenko wrote:
>> Hi, Julien!
>>
>> [snip]
>> On 28.10.21 13:48, Julien Grall wrote:
>>> Hi Stefano,
>>>
>>> Looking at linux/arch/arm64/boot/dts/, there are a few Device-Tree that
>>> contain the property "linux,p
On 25/10/2021 12:37, Oleksandr Andrushchenko wrote:
Hi, Julien!
Hi Oleksandr,
On 13.10.21 19:17, Julien Grall wrote:
On 08/10/2021 06:55, Oleksandr Andrushchenko wrote:
+ };
naddr = dt_number_of_address(dev);
@@ -1884,7 +1889,6 @@ static int __init handle_device(struct dom
Hi, Julien!
On 28.10.21 14:13, Julien Grall wrote:
>
>
> On 25/10/2021 12:37, Oleksandr Andrushchenko wrote:
>> Hi, Julien!
>
> Hi Oleksandr,
>
>> On 13.10.21 19:17, Julien Grall wrote:
>>> On 08/10/2021 06:55, Oleksandr Andrushchenko wrote:
+ };
naddr = dt_number_of_address(
flight 165921 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165921/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf bb146ce32dd8edc463e792554351e50b9e5b769f
baseline version:
ovmf 9a95d11023ac2f2ee49a2
On 27.10.21 19:02, Ian Jackson wrote:
The existing code depends on precisely whether the non-default option
appearing in the configure script is indeed the opposite of the option
we want to pass.
Right now it seems to be working but this seems fragile. Do it
differently.
I have verified that w
On Thu, Oct 28, 2021 at 12:16:54AM +0300, Dmitry Osipenko wrote:
> Use devm_register_power_handler() that replaces global pm_power_off_prepare
> variable and allows to register multiple power-off handlers.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
On Thu, Oct 28, 2021 at 12:16:40AM +0300, Dmitry Osipenko wrote:
> Kernel now supports chained power-off handlers. Use do_kernel_power_off()
> that invokes chained power-off handlers. It also invokes legacy
> pm_power_off() for now, which will be removed once all drivers will
> be converted to the
Hi, Julien!
On 27.10.21 20:35, Julien Grall wrote:
> Hi Oleksandr,
>
> On 27/10/2021 09:25, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> While in vPCI MMIO trap handlers for the guest PCI host bridge it is not
>> enough for SBDF translation to simply call VPCI_ECAM_BDF(in
Hi Julien,
On 27.10.2021 19:02, Julien Grall wrote:
>
>
> On 27/10/2021 11:41, Michal Orzel wrote:
>> Hi Julien,
>
> Hi Michal,
>
>> On 26.10.2021 18:56, Julien Grall wrote:
>>> Hi,
>>>
>>> On 26/10/2021 17:28, Julien Grall wrote:
On 26/10/2021 13:29, Michal Orzel wrote:
> If a device
On 10/6/21 8:43 AM, Boris Ostrovsky wrote:
On 10/6/21 2:19 AM, Juergen Gross wrote:
xen_pvh_init() is lacking a prototype in a header, add it.
Reported-by: kernel test robot
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
Applied to for-linus-5.16
-boris
Roger Pau Monne writes ("[PATCH for-4.16 v3] gnttab: allow setting max version
per-domain"):
> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> index 55c4881205..21a39adb70 100644
> --- a/docs/man/xl.cfg.5.pod.in
> +++ b/docs/man/xl.cfg.5.pod.in
> @@ -580,6 +580,12 @@ to have. Th
flight 165919 xen-unstable real [real]
flight 165923 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165919/
http://logs.test-lab.xenproject.org/osstest/logs/165923/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On 28/10/2021 08:31, Roger Pau Monné wrote:
> On Wed, Oct 27, 2021 at 09:07:13PM +0100, Andrew Cooper wrote:
>> GCC master (nearly version 12) complains:
>>
>> hvm.c: In function 'hvm_gsi_eoi':
>> hvm.c:905:10: error: the comparison will always evaluate as 'true' for the
>> address of 'dpci'
Hi Julien,
On 28.10.2021 12:05, Julien Grall wrote:
> Hi Stefano,
>
> First apologies for sending the previous e-mails in HTML (thanks for pointing
> that out!).
>
> On 28/10/2021 01:20, Stefano Stabellini wrote:
>> On Thu, 28 Oct 2021, Julien Grall wrote:
>>> On Thu, 28 Oct 2021, 00:14 Stefano
Dmitry Osipenko 於 2021年10月28日 週四 上午5:18寫道：
>
> Kernel now supports chained power-off handlers. Use do_kernel_power_off()
> that invokes chained power-off handlers. It also invokes legacy
> pm_power_off() for now, which will be removed once all drivers will
> be converted to the new power-off API.
Juergen Gross writes ("Re: [OSSTEST PATCH 0/2] ts-xen-build: explicitly
enable/disable configure features"):
> Far from being a Perl expert I agree this is a sensible approach and it
> should do the right thing.
>
> It will still depend on no unsupported option being mentioned in any
> comment, e
On Thu, Oct 28, 2021 at 01:12:31PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH for-4.16 v3] gnttab: allow setting max
> version per-domain"):
> > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> > index 55c4881205..21a39adb70 100644
> > --- a/docs/man/xl.cfg.5.pod
flight 165920 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165920/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 165682
build-i386-xsm
On 28/10/2021 13:09, Oleksandr Andrushchenko wrote:
Hi, Julien!
Hello,
On 27.10.21 20:35, Julien Grall wrote:
Hi Oleksandr,
On 27/10/2021 09:25, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
While in vPCI MMIO trap handlers for the guest PCI host bridge it is not
enough fo
On Thu, Oct 28, 2021 at 01:15:13PM +0100, Andrew Cooper wrote:
> On 28/10/2021 08:31, Roger Pau Monné wrote:
> > On Wed, Oct 27, 2021 at 09:07:13PM +0100, Andrew Cooper wrote:
> >> GCC master (nearly version 12) complains:
> >>
> >> hvm.c: In function 'hvm_gsi_eoi':
> >> hvm.c:905:10: error: th
On Thu, Oct 28, 2021 at 12:09:23PM +, Oleksandr Andrushchenko wrote:
> Hi, Julien!
>
> On 27.10.21 20:35, Julien Grall wrote:
> > Hi Oleksandr,
> >
> > On 27/10/2021 09:25, Oleksandr Andrushchenko wrote:
> >> From: Oleksandr Andrushchenko
> >>
> >> While in vPCI MMIO trap handlers for the gue
On 28/10/2021 13:15, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 28.10.2021 12:05, Julien Grall wrote:
The purpose of this patch is to fix the issue that is present in 4.16.
I think this is a latent bug (see more below).
The patch adding support for removal you are reffering to:
-is i
Julien Grall writes ("Re: [patch-4.16] arm/smmuv1,v2: Protect smmu master list
with a lock"):
> Right. PCI passthrough is not going to work in 4.16 whether this patch
> is merged or not. We are past the code freeze and as you said the code
> (and potentially the locking) is going to be reworked
Roger Pau Monné writes ("Re: [PATCH for-4.16 v3] gnttab: allow setting max
version per-domain"):
> Would you like me to this to the commit message:
>
> "xenstored stubdomains are limited to grant table v1 because the
> current MiniOS code used to build them only has support for grants v1.
> There
On 28.10.21 16:22, Julien Grall wrote:
> On 28/10/2021 13:09, Oleksandr Andrushchenko wrote:
>> Hi, Julien!
>
> Hello,
>
>> On 27.10.21 20:35, Julien Grall wrote:
>>> Hi Oleksandr,
>>>
>>> On 27/10/2021 09:25, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
While in v
On Thu, 28 Oct 2021, Anthony PERARD wrote:
> On Wed, Oct 27, 2021 at 02:43:46PM -0700, Stefano Stabellini wrote:
> > On Wed, 27 Oct 2021, Anthony PERARD wrote:
> > > > But we do have a severe problem at the moment with external sources: our
> > > > "git clones" keep failing during the build on x86.
On 28.10.21 16:36, Roger Pau Monné wrote:
> On Thu, Oct 28, 2021 at 12:09:23PM +, Oleksandr Andrushchenko wrote:
>> Hi, Julien!
>>
>> On 27.10.21 20:35, Julien Grall wrote:
>>> Hi Oleksandr,
>>>
>>> On 27/10/2021 09:25, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
>
Hi,
On 28/10/2021 15:16, Oleksandr Andrushchenko wrote:
On 28.10.21 16:22, Julien Grall wrote:
On 28/10/2021 13:09, Oleksandr Andrushchenko wrote:
Hi, Julien!
Hello,
On 27.10.21 20:35, Julien Grall wrote:
Hi Oleksandr,
On 27/10/2021 09:25, Oleksandr Andrushchenko wrote:
From: Oleksandr
On 21.10.21 16:41, Jan Beulich wrote:
On 15.10.2021 14:51, Juergen Gross wrote:
Instead of using a function table use the generated switch statement
macros for calling the appropriate hypercall handlers.
This is beneficial to performance and avoids speculation issues.
With calling the handlers
On 21.10.21 17:19, Jan Beulich wrote:
On 15.10.2021 14:51, Juergen Gross wrote:
The HVM hypercall handler is missing incrementing the per hypercall
counters. Add that.
The counters for PV are handled wrong, as they are not using
perf_incra() with the number of the hypercall as index, but are
in
From: Oleksandr Andrushchenko
Xen-pciback driver was designed to be built for x86 only. But it
can also be used by other architectures, e.g. Arm.
Currently PCI backend implements multiple functionalities at a time,
such as:
1. It is used as a database for assignable PCI devices, e.g. xl
pci-a
Please ignore this patch in favor of "RESEND PATCH v6" due to
a warning reported by kernel test robot :
I love your patch! Perhaps something to improve:
[auto build test WARNING on xen-tip/linux-next]
[also build test WARNING on linux/master linus/master v5.15-rc7 next-20211028]
[canno
On 28.10.21 17:28, Julien Grall wrote:
> Hi,
>
> On 28/10/2021 15:16, Oleksandr Andrushchenko wrote:
>> On 28.10.21 16:22, Julien Grall wrote:
>>> On 28/10/2021 13:09, Oleksandr Andrushchenko wrote:
Hi, Julien!
>>>
>>> Hello,
>>>
On 27.10.21 20:35, Julien Grall wrote:
> Hi Oleksandr
Hi,
On 28/10/2021 16:27, Oleksandr Andrushchenko wrote:
bridge as private and using info->gpa - GUEST_VPCI_ECAM_BASE...
So, I would stay with simpler
if ( bridge )
{
sbdf.sbdf = VPCI_ECAM_BDF(info->gpa - bridge->cfg->phys_addr);
sbdf.seg = bridge->segmen
Julien Grall writes ("Re: [PATCH] xen/arm: fix SBDF calculation for vPCI MMIO
handlers"):
> On 28/10/2021 16:27, Oleksandr Andrushchenko wrote:
> > bridge as private and using info->gpa - GUEST_VPCI_ECAM_BASE...
> > So, I would stay with simpler
> >
> > if ( bridge )
> > {
> >
On Thu, Oct 28, 2021 at 02:23:34PM +, Oleksandr Andrushchenko wrote:
>
>
> On 28.10.21 16:36, Roger Pau Monné wrote:
> > On Thu, Oct 28, 2021 at 12:09:23PM +, Oleksandr Andrushchenko wrote:
> >> Hi, Julien!
> >>
> >> On 27.10.21 20:35, Julien Grall wrote:
> >>> Hi Oleksandr,
> >>>
> >>> O
On Tue, 26 Oct 2021, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> The main reason of this change is that unpopulated-alloc
> code cannot be used in its current form on Arm, but there
> is a desire to reuse it to avoid wasting real RAM pages
> for the grant/foreign mappings.
>
> T
On Thu, 28 Oct 2021, Juergen Gross wrote:
> On 28.10.21 01:24, Stefano Stabellini wrote:
> > On Wed, 27 Oct 2021, Stefano Stabellini wrote:
> > > On Wed, 27 Oct 2021, Juergen Gross wrote:
> > > > On 26.10.21 02:54, Stefano Stabellini wrote:
> > > > > On Mon, 25 Oct 2021, Juergen Gross wrote:
> > >
On Thu, 28 Oct 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 28/10/2021 00:57, Stefano Stabellini wrote:
> > On Wed, 27 Oct 2021, Julien Grall wrote:
> > > Hi Oleksandr,
> > >
> > > On 27/10/2021 09:37, Oleksandr Andrushchenko wrote:
> > > > From: Oleksandr Andrushchenko
> > > >
> > > > If a P
On 28.10.21 19:03, Roger Pau Monné wrote:
> On Thu, Oct 28, 2021 at 02:23:34PM +, Oleksandr Andrushchenko wrote:
>>
>> On 28.10.21 16:36, Roger Pau Monné wrote:
>>> On Thu, Oct 28, 2021 at 12:09:23PM +, Oleksandr Andrushchenko wrote:
Hi, Julien!
On 27.10.21 20:35, Julien Gr
On 28.10.21 18:35, Julien Grall wrote:
> Hi,
>
> On 28/10/2021 16:27, Oleksandr Andrushchenko wrote:
>> bridge as private and using info->gpa - GUEST_VPCI_ECAM_BASE...
>> So, I would stay with simpler
>>
>> if ( bridge )
>> {
>> sbdf.sbdf = VPCI_ECAM_BDF(info->gpa - br
On 28.10.21 19:50, Stefano Stabellini wrote:
> On Thu, 28 Oct 2021, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 28/10/2021 00:57, Stefano Stabellini wrote:
>>> On Wed, 27 Oct 2021, Julien Grall wrote:
Hi Oleksandr,
On 27/10/2021 09:37, Oleksandr Andrushchenko wrote:
> From: Ole
On 10/28/21 6:59 AM, Juergen Gross wrote:
+
+ while (current_credit())
+ schedule_timeout_interruptible(HZ / 10);
Should we be concerned that we may get stuck here forever if for some reason we
can't balloon down everything?
-boris
On Thu, 28 Oct 2021, Oleksandr Andrushchenko wrote:
> On 28.10.21 19:50, Stefano Stabellini wrote:
> > On Thu, 28 Oct 2021, Julien Grall wrote:
> >> Hi Stefano,
> >>
> >> On 28/10/2021 00:57, Stefano Stabellini wrote:
> >>> On Wed, 27 Oct 2021, Julien Grall wrote:
> Hi Oleksandr,
>
>
On 10/26/21 12:05 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
If memremap_pages() succeeds the range is guaranteed to have proper page
table, there is no need for an additional virt_addr_valid() check.
Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Boris Ostrovsky
On 10/26/21 12:05 PM, Oleksandr Tyshchenko wrote:
+static void unpopulated_init(void)
+{
+ static bool inited = false;
+ int ret;
+
+ if (inited)
+ return;
+
+ /*
+* Try to initialize Xen resource the first and fall back to default
+* res
flight 165924 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165924/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in
165919 pass in 165924
test-amd64-am
On Thu, Oct 28, 2021 at 12:59:52PM +0200, Juergen Gross wrote:
> When running as PVH or HVM guest with actual memory < max memory the
> hypervisor is using "populate on demand" in order to allow the guest
> to balloon down from its maximum memory size. For this to work
> correctly the guest must no
On Thu, 28 Oct 2021, Julien Grall wrote:
> Hi Stefano,
>
> First apologies for sending the previous e-mails in HTML (thanks for pointing
> that out!).
>
> On 28/10/2021 01:20, Stefano Stabellini wrote:
> > On Thu, 28 Oct 2021, Julien Grall wrote:
> > > On Thu, 28 Oct 2021, 00:14 Stefano Stabellin
On Mon, 25 Oct 2021, Dongli Zhang wrote:
> The guest may access the pv vcpu_time_info immediately after
> VCPUOP_register_vcpu_info. This is to borrow the idea of
> VCPUOP_register_vcpu_time_memory_area, where the
> force_update_vcpu_system_time() is called immediately when the new memory
> area is
28.10.2021 14:00, Andy Shevchenko пишет:
> On Thu, Oct 28, 2021 at 12:16:33AM +0300, Dmitry Osipenko wrote:
>> Add atomic/blocking_notifier_has_unique_priority() helpers which return
>> true if given handler has unique priority.
>
> ...
>
>> +/**
>> + * atomic_notifier_has_unique_priority - Chec
28.10.2021 12:53, Rafael J. Wysocki пишет:
>> +/**
>> + * struct power_handler - Machine power-off + restart handler
>> + *
>> + * Describes power-off and restart handlers which are invoked by kernel
>> + * to power off or restart this machine. Supports prioritized chaining for
>> + * both restart
28.10.2021 12:59, Rafael J. Wysocki пишет:
>> +#define RESTART_PRIO_RESERVED 0
>> +#define RESTART_PRIO_DEFAULT 128
>> +#define RESTART_PRIO_HIGH 192
>>
>> enum reboot_mode {
>> REBOOT_UNDEFINED = -1,
>> @@ -49,6 +55,167 @@ int register_restart_handler(struc
28.10.2021 12:59, Rafael J. Wysocki пишет:
>> +/**
>> + * struct power_handler - Machine power-off + restart handler
>> + *
>> + * Describes power-off and restart handlers which are invoked by kernel
>> + * to power off or restart this machine. Supports prioritized chaining for
>> + * both restart
28.10.2021 00:16, Dmitry Osipenko пишет:
> mfd: ab8500: Use devm_register_trivial_power_off_handler()
> reset: ath79: Use devm_register_simple_restart_handler()
> reset: intel-gw: Use devm_register_simple_restart_handler()
> reset: lpc18xx: Use devm_register_prioritized_restart_handler()
>
28.10.2021 14:00, Andy Shevchenko пишет:
>> +while ((*nl) != NULL && (*nl)->priority >= n->priority) {
> ' != NULL' is not needed.
>
I'll change it in v3, thanks.
The `ljmp *mem` instruction is (famously?) not binary compatible between Intel
and AMD CPUS. The AMD-compatible version would require .long to be .quad in
the second hunk.
Switch to using lretq, which is compatible between Intel and AMD, as well as
being less logic overall.
Fixes: 5a82d5cf352d (
29.10.2021 00:32, Dmitry Osipenko пишет:
>>> + /*
>>> +* This code gets used during boot-up, when task switching is
>>> +* not yet working and interrupts must remain disabled. At
>> One space is enough.
> This comment is replicated multiple times over this source file. You can
> find it
On Tue, Sep 21, 2021 at 03:07:25PM -0700, Julius Werner wrote:
> > Since it doesn't seem possible to have each boot component using the same
> > log
> > format, we added a log_format and log_phys_addr fields to give flexibility
> > in
> > how logs are stored. An example of a different log format
flight 165926 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165926/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 165682
build-i386-xsm
On 28.10.21 22:16, Marek Marczykowski-Górecki wrote:
On Thu, Oct 28, 2021 at 12:59:52PM +0200, Juergen Gross wrote:
When running as PVH or HVM guest with actual memory < max memory the
hypervisor is using "populate on demand" in order to allow the guest
to balloon down from its maximum memory si
flight 165927 linux-linus real [real]
flight 165930 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165927/
http://logs.test-lab.xenproject.org/osstest/logs/165930/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
On 28.10.21 18:41, Stefano Stabellini wrote:
On Thu, 28 Oct 2021, Juergen Gross wrote:
On 28.10.21 01:24, Stefano Stabellini wrote:
On Wed, 27 Oct 2021, Stefano Stabellini wrote:
On Wed, 27 Oct 2021, Juergen Gross wrote:
On 26.10.21 02:54, Stefano Stabellini wrote:
On Mon, 25 Oct 2021, Juerg
flight 165928 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165928/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 165682
build-i386-xsm
91 matches
Mail list logo
