Hi Jan
> -Original Message-
> From: Jan Beulich
> Sent: Wednesday, March 30, 2022 5:59 PM
> To: Penny Zheng
> Cc: Wei Chen ; Henry Wang ;
> Andrew Cooper ; George Dunlap
> ; Julien Grall ; Stefano Stabellini
> ; Wei Liu ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v1 4/5] xe
While not triggered by the trivial xen_nop in-tree patch on
staging/master, that patch exposes a problem on the stable trees, where
all functions have ENDBR inserted. When NOP-ing out a range, we need to
account for this. Handle this right in livepatch_insn_len().
This requires livepatch_insn_len(
On 30.03.2022 19:04, Roger Pau Monné wrote:
> On Wed, Mar 30, 2022 at 01:05:31PM +0200,>> --- a/xen/arch/x86/livepatch.c
>> +++ b/xen/arch/x86/livepatch.c
>> @@ -157,9 +157,15 @@ void noinline arch_livepatch_apply(struc
>> * loaded hotpatch (to avoid racing against other fixups adding/removin
On 31.03.22 05:51, Marek Marczykowski-Górecki wrote:
Hi,
I'm trying to make use of CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y to increase
domain memory beyond initial maxmem, but I hit few issues.
A little context: domains in Qubes OS start with rather little memory
(400MB by default) but maxmem set h
branch xen-4.14-testing
xenbranch xen-4.14-testing
job test-amd64-amd64-livepatch
testid livepatch-run
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.x
Hi Jan
> -Original Message-
> From: Jan Beulich
> Sent: Wednesday, March 30, 2022 5:53 PM
> To: Penny Zheng
> Cc: Wei Chen ; Henry Wang ;
> Andrew Cooper ; George Dunlap
> ; Julien Grall ; Stefano Stabellini
> ; Wei Liu ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v1 3/5] xe
On 3/30/22 2:45 PM, Jason Andryuk wrote:
On Fri, Mar 18, 2022 at 4:13 AM Jan Beulich wrote:
On 14.03.2022 04:41, Chuck Zmudzinski wrote:
When gfx_passthru is enabled for the Intel IGD, hvmloader maps the IGD
opregion to the guest but libxl does not grant the guest permission to
access the mapp
On 3/30/22 1:27 PM, Andrew Cooper wrote:
On 30/03/2022 18:15, Anthony PERARD wrote:
Some more though on that, looking at QEMU, it seems that there's already
a call to xc_domain_iomem_permission(), in igd_write_opregion().
This has been discussed before, but noone's done anything about it.
It's
Hi,
I'm trying to make use of CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y to increase
domain memory beyond initial maxmem, but I hit few issues.
A little context: domains in Qubes OS start with rather little memory
(400MB by default) but maxmem set higher (4GB by default). Then, there is
qmemman daemon,
branch xen-4.15-testing
xenbranch xen-4.15-testing
job test-amd64-amd64-livepatch
testid livepatch-run
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.x
On 3/30/22 1:15 PM, Anthony PERARD wrote:
Hi Chuck,
On Sun, Mar 13, 2022 at 11:41:37PM -0400, Chuck Zmudzinski wrote:
When gfx_passthru is enabled for the Intel IGD, hvmloader maps the IGD
opregion to the guest but libxl does not grant the guest permission to
I'm not reading the same thing whe
flight 168997 linux-linus real [real]
flight 169051 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168997/
http://logs.test-lab.xenproject.org/osstest/logs/169051/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
On Tue, Mar 29, 2022 at 08:27:24AM +0200, Jan Beulich wrote:
> On 29.03.2022 00:25, Stefano Stabellini wrote:
> > On Sat, 26 Mar 2022, Elliott Mitchell wrote:
> >> The hypercalls implementation for Linux and FreeBSD have two key headers,
> >> hypercall.h and hypervisor.h. I'm curious why the imple
flight 169009 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169009/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
flight 168993 xen-4.16-testing real [real]
flight 169042 xen-4.16-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168993/
http://logs.test-lab.xenproject.org/osstest/logs/169042/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
flight 169004 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169004/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 168254
build-amd64-xsm
flight 168992 xen-4.15-testing real [real]
flight 169036 xen-4.15-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168992/
http://logs.test-lab.xenproject.org/osstest/logs/169036/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
The EFI System Resource Table (ESRT) is necessary for fwupd to identify
firmware updates to install. According to the UEFI specification §23.4,
the table shall be stored in memory of type EfiBootServicesData.
Therefore, Xen must avoid reusing that memory for other purposes, so
that Linux can acces
On Wed, Mar 30, 2022 at 12:24 PM Daniel P. Smith
wrote:
>
> On 3/30/22 11:15, Jason Andryuk wrote:
> > On Wed, Mar 30, 2022 at 10:04 AM Daniel P. Smith
> > wrote:
> >>
> >> On 3/30/22 08:30, Jason Andryuk wrote:
> >>> On Wed, Mar 30, 2022 at 2:30 AM Jan Beulich wrote:
>
> On 29.03.2022
PCI device assignment to an HVM with stubdom is potentially racy. First
the PCI device is assigned to the stubdom via the PV PCI protocol. Then
QEMU is sent a QMP command to attach the PCI device to QEMU running
within the stubdom. However, the sysfs entries within the stubdom may
not have appea
It is now possible to promote the idle domain to privileged during setup. It
is not desirable for the idle domain to still be privileged when moving into a
running state. If the idle domain was elevated and not properly demoted, it is
desirable to fail at this point. This commit adds an assert for
There are now instances where internal hypervisor logic needs to make resource
allocation calls that are protected by XSM checks. The internal hypervisor logic
is represented a number of system domains which by designed are represented by
non-privileged struct domain instances. To enable these logi
This series introduces a pair of functions that allow a domain to be escalated
to
is_privileged or demoted. Internally the functions enforce the policy that this
is only allowed for system domains, the idle domain in particular.
As for the implementation, there is a desire that the logic does not
On Fri, Mar 18, 2022 at 4:13 AM Jan Beulich wrote:
>
> On 14.03.2022 04:41, Chuck Zmudzinski wrote:
> > When gfx_passthru is enabled for the Intel IGD, hvmloader maps the IGD
> > opregion to the guest but libxl does not grant the guest permission to
> > access the mapped memory region. This result
On 3/30/22 14:17, Jason Andryuk wrote:
> xsm_unmap_domain_irq was seen denying unmap_domain_pirq when called from
> complete_domain_destroy as an RCU callback. The source context was an
> unexpected, random domain. Since this is a xen-internal operation,
> we don't want the XSM hook denying the o
commit babde47a3fed "introduce a 'passthrough' configuration option to
xl.cfg..." moved the pci list parsing ahead of the global pci option
parsing. This broke the global pci configuration options since they
need to be set first so that looping over the pci devices assigns their
values.
Move the
xsm_unmap_domain_irq was seen denying unmap_domain_pirq when called from
complete_domain_destroy as an RCU callback. The source context was an
unexpected, random domain. Since this is a xen-internal operation,
we don't want the XSM hook denying the operation.
Check d->is_dying and skip the check
libxl__stubdomain_is_linux can take a const pointer, so make the change.
This isn't an issue in-tree, but was found with an OpenXT patch where it
was called with only const libxl_domain_build_info available.
Signed-off-by: Jason Andryuk
---
tools/libs/light/libxl_internal.h | 2 +-
1 file chang
I've observed this failed assertion:
libxl_event.c:2057: libxl__ao_inprogress_gc: Assertion `ao' failed.
AFAICT, this is happening in qmp_proxy_spawn_outcome where
sdss->qmp_proxy_spawn.ao is NULL.
The out label of spawn_stub_launch_dm calls qmp_proxy_spawn_outcome, but
it is only in the success
If domain_soft_reset_cb can't rename the save file, it doesn't call
initiate_domain_create() and calls domcreate_complete().
Skipping initiate_domain_create() means dcs->console_wait is
uninitialized and all 0s.
We have:
domcreate_complete()
libxl__xswait_stop()
libxl__ev_xswatch_dere
On 30/03/2022 18:15, Anthony PERARD wrote:
> Hi Chuck,
>
> On Sun, Mar 13, 2022 at 11:41:37PM -0400, Chuck Zmudzinski wrote:
>> When gfx_passthru is enabled for the Intel IGD, hvmloader maps the IGD
>> opregion to the guest but libxl does not grant the guest permission to
> I'm not reading the same
Hi Chuck,
On Sun, Mar 13, 2022 at 11:41:37PM -0400, Chuck Zmudzinski wrote:
> When gfx_passthru is enabled for the Intel IGD, hvmloader maps the IGD
> opregion to the guest but libxl does not grant the guest permission to
I'm not reading the same thing when looking at code in hvmloader. It
seems
On Wed, Mar 30, 2022 at 01:05:31PM +0200, Jan Beulich wrote:
> While not triggered by the trivial xen_nop in-tree patch on
> staging/master, that patch exposes a problem on the stable trees, where
> all functions have ENDBR inserted. When NOP-ing out a range, we need to
> account for this. Handle t
On 3/30/22 11:15, Jason Andryuk wrote:
> On Wed, Mar 30, 2022 at 10:04 AM Daniel P. Smith
> wrote:
>>
>> On 3/30/22 08:30, Jason Andryuk wrote:
>>> On Wed, Mar 30, 2022 at 2:30 AM Jan Beulich wrote:
On 29.03.2022 20:57, Daniel P. Smith wrote:
> On 3/29/22 02:43, Jan Beulich wrote:
>
On 3/30/22 11:15, Jason Andryuk wrote:
> On Wed, Mar 30, 2022 at 10:04 AM Daniel P. Smith
> wrote:
>>
>> On 3/30/22 08:30, Jason Andryuk wrote:
>>> On Wed, Mar 30, 2022 at 2:30 AM Jan Beulich wrote:
On 29.03.2022 20:57, Daniel P. Smith wrote:
> On 3/29/22 02:43, Jan Beulich wrote:
>
On Wed, Mar 30, 2022 at 10:04 AM Daniel P. Smith
wrote:
>
> On 3/30/22 08:30, Jason Andryuk wrote:
> > On Wed, Mar 30, 2022 at 2:30 AM Jan Beulich wrote:
> >>
> >> On 29.03.2022 20:57, Daniel P. Smith wrote:
> >>> On 3/29/22 02:43, Jan Beulich wrote:
> Similarly I don't see how things would
On Wed, Mar 30, 2022 at 04:55:52PM +0200, Jan Beulich wrote:
> On 30.03.2022 16:19, Roger Pau Monné wrote:
> > On Wed, Mar 30, 2022 at 01:05:31PM +0200, Jan Beulich wrote:
> >> While not triggered by the trivial xen_nop in-tree patch on
> >> staging/master, that patch exposes a problem on the stabl
On Wed, Mar 30, 2022 at 09:42:18AM -0400, Daniel P. Smith wrote:
> On 3/30/22 05:40, Roger Pau Monné wrote:
> > On Tue, Mar 29, 2022 at 07:12:56PM -0400, Daniel P. Smith wrote:
> >> On 3/29/22 03:29, Roger Pau Monné wrote:
> >>> On Mon, Mar 28, 2022 at 04:36:22PM -0400, Daniel P. Smith wrote:
> >>>
On 30.03.2022 16:19, Roger Pau Monné wrote:
> On Wed, Mar 30, 2022 at 01:05:31PM +0200, Jan Beulich wrote:
>> While not triggered by the trivial xen_nop in-tree patch on
>> staging/master, that patch exposes a problem on the stable trees, where
>> all functions have ENDBR inserted. When NOP-ing out
flight 168986 xen-4.14-testing real [real]
flight 169025 xen-4.14-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168986/
http://logs.test-lab.xenproject.org/osstest/logs/169025/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
On Wed, Mar 30, 2022, 9:34 AM Jan Beulich wrote:
> On 30.03.2022 15:19, Tamas K Lengyel wrote:
> > On Wed, Mar 30, 2022, 6:31 AM Jan Beulich wrote:
> >> On 29.03.2022 16:03, Tamas K Lengyel wrote:
> >>> --- a/xen/arch/x86/include/asm/mem_sharing.h
> >>> +++ b/xen/arch/x86/include/asm/mem_sharing
On Wed, Mar 30, 2022 at 01:05:31PM +0200, Jan Beulich wrote:
> While not triggered by the trivial xen_nop in-tree patch on
> staging/master, that patch exposes a problem on the stable trees, where
> all functions have ENDBR inserted. When NOP-ing out a range, we need to
> account for this. Handle t
On 3/30/22 08:30, Jason Andryuk wrote:
> On Wed, Mar 30, 2022 at 2:30 AM Jan Beulich wrote:
>>
>> On 29.03.2022 20:57, Daniel P. Smith wrote:
>>> On 3/29/22 02:43, Jan Beulich wrote:
Similarly I don't see how things would work transparently with a
Flask policy in place. Regardless of you
On 3/30/22 02:30, Jan Beulich wrote:
> On 29.03.2022 20:57, Daniel P. Smith wrote:
>> On 3/29/22 02:43, Jan Beulich wrote:
>>> On 28.03.2022 22:36, Daniel P. Smith wrote:
During domain construction under dom0less and hyperlaunch it is necessary
to
allocate at least the event channel
On 3/30/22 05:40, Roger Pau Monné wrote:
> On Tue, Mar 29, 2022 at 07:12:56PM -0400, Daniel P. Smith wrote:
>> On 3/29/22 03:29, Roger Pau Monné wrote:
>>> On Mon, Mar 28, 2022 at 04:36:22PM -0400, Daniel P. Smith wrote:
During domain construction under dom0less and hyperlaunch it is necessary
On 30/03/2022 14:36, Jan Beulich wrote:
On 30.03.2022 15:30, Julien Grall wrote:
Hi,
On 30/03/2022 14:24, Michal Orzel wrote:
On 30.03.2022 14:53, Jan Beulich wrote:
On 30.03.2022 14:13, Michal Orzel wrote:
On 30.03.2022 13:57, Jan Beulich wrote:
On 30.03.2022 13:04, Michal Orzel wrote
On 30.03.2022 15:30, Julien Grall wrote:
> Hi,
>
> On 30/03/2022 14:24, Michal Orzel wrote:
>>
>>
>> On 30.03.2022 14:53, Jan Beulich wrote:
>>> On 30.03.2022 14:13, Michal Orzel wrote:
On 30.03.2022 13:57, Jan Beulich wrote:
> On 30.03.2022 13:04, Michal Orzel wrote:
>> On 30.03.2022
On 30.03.2022 15:19, Tamas K Lengyel wrote:
> On Wed, Mar 30, 2022, 6:31 AM Jan Beulich wrote:
>> On 29.03.2022 16:03, Tamas K Lengyel wrote:
>>> --- a/xen/arch/x86/include/asm/mem_sharing.h
>>> +++ b/xen/arch/x86/include/asm/mem_sharing.h
>>> @@ -85,6 +85,9 @@ static inline bool mem_sharing_is_fo
Hi,
On 30/03/2022 14:24, Michal Orzel wrote:
On 30.03.2022 14:53, Jan Beulich wrote:
On 30.03.2022 14:13, Michal Orzel wrote:
On 30.03.2022 13:57, Jan Beulich wrote:
On 30.03.2022 13:04, Michal Orzel wrote:
On 30.03.2022 12:42, Jan Beulich wrote:
On 30.03.2022 12:32, Julien Grall wrote:
On 30.03.2022 15:24, Michal Orzel wrote:
> On 30.03.2022 14:53, Jan Beulich wrote:
>> On 30.03.2022 14:13, Michal Orzel wrote:
>>> On 30.03.2022 13:57, Jan Beulich wrote:
On 30.03.2022 13:04, Michal Orzel wrote:
> On 30.03.2022 12:42, Jan Beulich wrote:
>> On 30.03.2022 12:32, Julien G
On 30.03.2022 14:53, Jan Beulich wrote:
> On 30.03.2022 14:13, Michal Orzel wrote:
>> On 30.03.2022 13:57, Jan Beulich wrote:
>>> On 30.03.2022 13:04, Michal Orzel wrote:
On 30.03.2022 12:42, Jan Beulich wrote:
> On 30.03.2022 12:32, Julien Grall wrote:
>> Renaming to PE_COFF may he
On Wed, Mar 30, 2022, 6:31 AM Jan Beulich wrote:
> On 29.03.2022 16:03, Tamas K Lengyel wrote:
> > --- a/xen/arch/x86/include/asm/mem_sharing.h
> > +++ b/xen/arch/x86/include/asm/mem_sharing.h
> > @@ -85,6 +85,9 @@ static inline bool mem_sharing_is_fork(const struct
> domain *d)
> > int mem_shar
Hey Julien,
On 3/29/22 17:57, Julien Grall wrote:
> Hi Daniel,
>
> On 29/03/2022 19:57, Daniel P. Smith wrote:
>> On 3/29/22 02:43, Jan Beulich wrote:
>>> On 28.03.2022 22:36, Daniel P. Smith wrote:
During domain construction under dom0less and hyperlaunch it is
necessary to
alloca
On 30.03.2022 14:13, Michal Orzel wrote:
> On 30.03.2022 13:57, Jan Beulich wrote:
>> On 30.03.2022 13:04, Michal Orzel wrote:
>>> On 30.03.2022 12:42, Jan Beulich wrote:
On 30.03.2022 12:32, Julien Grall wrote:
> Renaming to PE_COFF may help to avoid the confusion with CONFIG_EFI.
>
On Wed, Mar 30, 2022 at 2:30 AM Jan Beulich wrote:
>
> On 29.03.2022 20:57, Daniel P. Smith wrote:
> > On 3/29/22 02:43, Jan Beulich wrote:
> >> Similarly I don't see how things would work transparently with a
> >> Flask policy in place. Regardless of you mentioning the restriction,
> >> I think t
On Wed, Mar 30, 2022, 2:47 AM Jan Beulich wrote:
> On 29.03.2022 18:10, Tamas K Lengyel wrote:
> > On Tue, Mar 29, 2022 at 11:42 AM Jan Beulich wrote:
> >>
> >> On 29.03.2022 16:03, Tamas K Lengyel wrote:
> >>> Add option to the fork memop to enforce a start with an empty p2m.
> >>> Pre-populati
branch xen-4.15-testing
xenbranch xen-4.15-testing
job test-amd64-i386-livepatch
testid livepatch-run
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xe
On 30.03.2022 13:57, Jan Beulich wrote:
> On 30.03.2022 13:04, Michal Orzel wrote:
>> Hello,
>>
>> On 30.03.2022 12:42, Jan Beulich wrote:
>>> On 30.03.2022 12:32, Julien Grall wrote:
On 29/03/2022 12:42, Jan Beulich wrote:
> On 29.03.2022 12:54, Julien Grall wrote:
>> On 29/03/2022
On 30.03.2022 13:04, Michal Orzel wrote:
> Hello,
>
> On 30.03.2022 12:42, Jan Beulich wrote:
>> On 30.03.2022 12:32, Julien Grall wrote:
>>> On 29/03/2022 12:42, Jan Beulich wrote:
On 29.03.2022 12:54, Julien Grall wrote:
> On 29/03/2022 11:12, Michal Orzel wrote:
>> On 29.03.2022 11
While not triggered by the trivial xen_nop in-tree patch on
staging/master, that patch exposes a problem on the stable trees, where
all functions have ENDBR inserted. When NOP-ing out a range, we need to
account for this. Handle this right in livepatch_insn_len().
This requires livepatch_insn_len(
Hello,
On 30.03.2022 12:42, Jan Beulich wrote:
> On 30.03.2022 12:32, Julien Grall wrote:
>> On 29/03/2022 12:42, Jan Beulich wrote:
>>> On 29.03.2022 12:54, Julien Grall wrote:
On 29/03/2022 11:12, Michal Orzel wrote:
> On 29.03.2022 11:54, Julien Grall wrote:
>> On 22/03/2022 08:02,
On 30.03.2022 12:43, Jan Beulich wrote:
> On 30.03.2022 12:19, Roger Pau Monné wrote:
>> On Wed, Mar 30, 2022 at 10:03:11AM +0200, Jan Beulich wrote:
>>> While not triggered by the trivial xen_nop in-tree patch on
>>> staging/master, that patch exposes a problem on the stable trees, where
>>> all f
On 30.03.2022 12:19, Roger Pau Monné wrote:
> On Wed, Mar 30, 2022 at 10:03:11AM +0200, Jan Beulich wrote:
>> While not triggered by the trivial xen_nop in-tree patch on
>> staging/master, that patch exposes a problem on the stable trees, where
>> all functions have ENDBR inserted. When NOP-ing out
On 30.03.2022 12:32, Julien Grall wrote:
> On 29/03/2022 12:42, Jan Beulich wrote:
>> On 29.03.2022 12:54, Julien Grall wrote:
>>> On 29/03/2022 11:12, Michal Orzel wrote:
On 29.03.2022 11:54, Julien Grall wrote:
> On 22/03/2022 08:02, Michal Orzel wrote:
>> --- a/xen/include/xen/xen.l
On 30.03.2022 12:21, Roger Pau Monné wrote:
> On Fri, Feb 18, 2022 at 03:45:12PM +, Andrew Cooper wrote:
>> On 18/02/2022 14:34, Roger Pau Monne wrote:
>>> Hello,
>>>
>>> The following series adds retpoline support for clang builds, and also
>>> allows the user to select whether to enable retpo
Hi Jan,
On 29/03/2022 12:42, Jan Beulich wrote:
On 29.03.2022 12:54, Julien Grall wrote:
On 29/03/2022 11:12, Michal Orzel wrote:
On 29.03.2022 11:54, Julien Grall wrote:
On 22/03/2022 08:02, Michal Orzel wrote:
--- a/xen/include/xen/xen.lds.h
+++ b/xen/include/xen/xen.lds.h
@@ -5,4 +5,104 @
On 29.03.2022 16:03, Tamas K Lengyel wrote:
> --- a/xen/arch/x86/include/asm/mem_sharing.h
> +++ b/xen/arch/x86/include/asm/mem_sharing.h
> @@ -85,6 +85,9 @@ static inline bool mem_sharing_is_fork(const struct domain
> *d)
> int mem_sharing_fork_page(struct domain *d, gfn_t gfn,
>
On Fri, Feb 18, 2022 at 03:45:12PM +, Andrew Cooper wrote:
> On 18/02/2022 14:34, Roger Pau Monne wrote:
> > Hello,
> >
> > The following series adds retpoline support for clang builds, and also
> > allows the user to select whether to enable retpoline support at build
> > time via a new Kconfi
On Wed, Mar 30, 2022 at 10:03:11AM +0200, Jan Beulich wrote:
> While not triggered by the trivial xen_nop in-tree patch on
> staging/master, that patch exposes a problem on the stable trees, where
> all functions have ENDBR inserted. When NOP-ing out a range, we need to
> account for this. Handle t
All,
while 4.14's general support period ended in January, we're considering
to cut an out-of-band release due to the relatively large number of
security relevant backports which has accumulated in just 2 months. By
doing this we would _not_ be promising to do so again in the future.
Please voice
On 30.03.2022 11:36, Penny Zheng wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -249,6 +249,26 @@ static void populate_physmap(struct memop_args *a)
>
> mfn = _mfn(gpfn);
> }
> +#ifdef CONFIG_STATIC_MEMORY
> +else if ( is_domain_on_st
On 30.03.2022 11:36, Penny Zheng wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -35,6 +35,10 @@
> #include
> #endif
>
> +#ifndef is_domain_on_static_allocation
> +#define is_domain_on_static_allocation(d) 0
Nit: "false", not "0".
> @@ -405,13 +409,29 @@ int guest_remove_
When domain on static allocation populates memory through populate_physmap,
other than allocating from heap, it shall allocate from resv_page_list to
make sure that all guest RAM are still restricted in statically configured
regions.
Signed-off-by: Penny Zheng
---
xen/common/memory.c | 20 ++
On Tue, Mar 29, 2022 at 07:12:56PM -0400, Daniel P. Smith wrote:
> On 3/29/22 03:29, Roger Pau Monné wrote:
> > On Mon, Mar 28, 2022 at 04:36:22PM -0400, Daniel P. Smith wrote:
> >> During domain construction under dom0less and hyperlaunch it is necessary
> >> to
> >> allocate at least the event c
When domain on static allocation and is directly mapped, in terms of
GPA == HPA(guest physical address == host physical address), we could use
mfn_to_page() to easily find the page, so there is no need to store pages
in resv_page_list.
Signed-off-by: Penny Zheng
---
xen/common/memory.c | 5 -
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 domain
on static allocation.
Guest RAM for domain on static allocation is static memory, which is reserved
to only this domain, so it shall never go back
With more and more CDF_xxx internal flags in and to save the space, this
commit introduces a new field "flags" to store CDF_* internal flags
directly.
Another new CDF_xxx will be introduced in the next patch.
Signed-off-by: Penny Zheng
---
xen/arch/arm/domain.c | 3 ++-
xen/arch/arm
In order to have an easy and quick way to find out whether this domain is
on static allocation, this commit introduces a new flag CDF_staticmem and a
new helper is_domain_on_static_allocation.
Signed-off-by: Penny Zheng
---
xen/arch/arm/domain_build.c | 5 -
xen/arch/arm/include/asm/do
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 domain
on static allocation.Since guest RAM for domain on static allocation is
static memory, which is pre-reserved through domain congifuration, it shall
On 07.03.2022 21:53, Andrew Cooper wrote:
> --- a/xen/arch/x86/machine_kexec.c
> +++ b/xen/arch/x86/machine_kexec.c
> @@ -156,6 +156,16 @@ void machine_kexec(struct kexec_image *image)
> */
> local_irq_disable();
>
> +/* Reset CPUID masking and faulting to the host's default. */
>
flight 168985 qemu-mainline real [real]
flight 169013 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168985/
http://logs.test-lab.xenproject.org/osstest/logs/169013/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
While not triggered by the trivial xen_nop in-tree patch on
staging/master, that patch exposes a problem on the stable trees, where
all functions have ENDBR inserted. When NOP-ing out a range, we need to
account for this. Handle this right in livepatch_insn_len().
Fixes: 6974c75180f1 ("xen/x86: Li
Hello,
We have a bunch of x86 boxes in the colo that are currently not
blessed for osstest usage because they were broken at some point, or
managed by a broken PDU. We believe this is all solved now.
I'm still running more commissioning flights ATM on other boxes, but I
think the noblings are rea
On 29.03.2022 20:06, osstest service owner wrote:
> flight 168970 xen-4.15-testing real [real]
> flight 168989 xen-4.15-testing real-retest [real]
> http://logs.test-lab.xenproject.org/osstest/logs/168970/
> http://logs.test-lab.xenproject.org/osstest/logs/168989/
>
> Regressions :-(
>
> Tests wh
84 matches
Mail list logo
