On 29.09.2020 20:17, Trammell Hudson wrote:
> +static int __init pe_name_compare(const struct PeSectionHeader *sect,
> + const CHAR16 *name)
> +{
> +size_t i;
> +
> +if ( sect->Name[0] != '.' )
> +return -1;
> +
> +for ( i = 1; i < sizeof(sect->N
> -Original Message-
> From: Jan Beulich
> Sent: 30 September 2020 07:42
> To: p...@xen.org
> Cc: xen-devel@lists.xenproject.org; 'Andrew Cooper'
> ; 'George Dunlap'
> ; 'Ian Jackson' ; 'Julien
> Grall' ;
> 'Wei Liu' ; 'Stefano Stabellini'
> Subject: Re: [PATCH 04/12] evtchn: evtchn_set
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 28 September 2020 12:02
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Ian
> Jackson ; Julien Grall ; Wei Liu
> ; Stefano Stabellini
>
> Subject: [PATCH 10/12] evtchn/fifo: use st
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 28 September 2020 12:01
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Ian
> Jackson ; Julien Grall ; Wei Liu
> ; Stefano Stabellini
>
> Subject: [PATCH 09/12] evtchn: move FIFO-p
On Tue, Sep 29, 2020 at 12:12:14PM +0200, David Hildenbrand wrote:
>On 29.09.20 11:18, Wei Yang wrote:
>> On Mon, Sep 28, 2020 at 08:21:08PM +0200, David Hildenbrand wrote:
>>> Page isolation doesn't actually touch the pages, it simply isolates
>>> pageblocks and moves all free pages to the MIGRATE
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 28 September 2020 12:02
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Ian
> Jackson ; Julien Grall ; Wei Liu
> ; Stefano Stabellini
>
> Subject: [PATCH 11/12] evtchn: convert vIRQ l
Am 29.09.20 um 19:49 schrieb Thomas Zimmermann:
Hi Christian
Am 29.09.20 um 17:35 schrieb Christian König:
Am 29.09.20 um 17:14 schrieb Thomas Zimmermann:
The new helper ttm_kmap_obj_to_dma_buf() extracts address and location
from and instance of TTM's kmap_obj and initializes struct dma_buf_m
Hi
Am 30.09.20 um 10:05 schrieb Christian König:
> Am 29.09.20 um 19:49 schrieb Thomas Zimmermann:
>> Hi Christian
>>
>> Am 29.09.20 um 17:35 schrieb Christian König:
>>> Am 29.09.20 um 17:14 schrieb Thomas Zimmermann:
The new helper ttm_kmap_obj_to_dma_buf() extracts address and location
>>>
On 30.09.2020 09:31, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 30 September 2020 07:42
>> To: p...@xen.org
>> Cc: xen-devel@lists.xenproject.org; 'Andrew Cooper'
>> ; 'George Dunlap'
>> ; 'Ian Jackson' ; 'Julien
>> Grall' ;
>> 'Wei Liu' ; 'Stefano Stabellini
On 30.09.2020 09:37, Paul Durrant wrote:
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 28 September 2020 12:01
>>
>> There's no need to expose them.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> I wonder whether we shouldn't do away with event_fifo.h altogether.
>>
>
> +1
>
> I can't se
Am 30.09.20 um 10:19 schrieb Thomas Zimmermann:
Hi
Am 30.09.20 um 10:05 schrieb Christian König:
Am 29.09.20 um 19:49 schrieb Thomas Zimmermann:
Hi Christian
Am 29.09.20 um 17:35 schrieb Christian König:
Am 29.09.20 um 17:14 schrieb Thomas Zimmermann:
The new helper ttm_kmap_obj_to_dma_buf(
On 30.09.2020 09:35, Paul Durrant wrote:
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 28 September 2020 12:02
>>
>> Both evtchn->priority and evtchn->notify_vcpu_id could, prior to recent
>> locking adjustments, change behind the back of
>> evtchn_fifo_set_pending(). Neither the queue'
> -Original Message-
> From: Jan Beulich
> Sent: 30 September 2020 09:32
> To: p...@xen.org
> Cc: xen-devel@lists.xenproject.org; 'Andrew Cooper'
> ; 'George Dunlap'
> ; 'Ian Jackson' ; 'Julien
> Grall' ;
> 'Wei Liu' ; 'Stefano Stabellini'
> Subject: Re: [PATCH 04/12] evtchn: evtchn_set
On 30.09.2020 09:58, Paul Durrant wrote:
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 28 September 2020 12:02
>>
>> @@ -334,6 +334,12 @@ void _spin_unlock_recursive(spinlock_t *
>> }
>> }
>>
>> +void _rw_barrier(rwlock_t *lock)
>> +{
>> +check_barrier(&lock->lock.debug);
>> +
> -Original Message-
> From: Jan Beulich
> Sent: 30 September 2020 09:35
> To: p...@xen.org
> Cc: xen-devel@lists.xenproject.org; 'Andrew Cooper'
> ; 'George Dunlap'
> ; 'Ian Jackson' ; 'Julien
> Grall' ;
> 'Wei Liu' ; 'Stefano Stabellini'
> Subject: Re: [PATCH 10/12] evtchn/fifo: use s
On Tue, Sep 29, 2020 at 04:05:21PM +0200, Jürgen Groß wrote:
> On 29.09.20 14:41, Marek Marczykowski-Górecki wrote:
> > On Tue, Sep 29, 2020 at 03:27:43PM +0300, Denis Efremov wrote:
> > > Hi,
> > >
> > > On 9/28/20 12:36 PM, Marek Marczykowski-Górecki wrote:
> > > > On Mon, Sep 28, 2020 at 07:02:
On 30.09.2020 10:36, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 30 September 2020 09:32
>>
>> On 30.09.2020 09:31, Paul Durrant wrote:
From: Jan Beulich
Sent: 30 September 2020 07:42
On 29.09.2020 18:31, Paul Durrant wrote:
>> From: Xen-devel On Behalf Of
>> J
Hi Jan,
On 29/09/2020 13:49, Jan Beulich wrote:
On 29.09.2020 14:26, Julien Grall wrote:
On 28/09/2020 12:00, Jan Beulich wrote:
There's no need to expose them.
We are going to need them for LiveUpdate and Non-cooperative Live
Migration as the save/restore is happening outside of event_fifo.
André Przywara writes:
> On 29/09/2020 22:11, Alex Bennée wrote:
>
> Hi,
>
>> Julien Grall writes:
>>
>>> Hi Alex,
>>>
>>> On 29/09/2020 16:29, Alex Bennée wrote:
Julien Grall writes:
> From: Julien Grall
>
> Hi all,
>
> Xen on ARM has been broken for quit
> -Original Message-
> From: Jan Beulich
> Sent: 30 September 2020 09:37
> To: p...@xen.org
> Cc: xen-devel@lists.xenproject.org; 'Andrew Cooper'
> ; 'George Dunlap'
> ; 'Ian Jackson' ; 'Julien
> Grall' ;
> 'Wei Liu' ; 'Stefano Stabellini'
> Subject: Re: [PATCH 11/12] evtchn: convert vI
Hi Jan,
On 30/09/2020 07:26, Jan Beulich wrote:
On 29.09.2020 19:18, Julien Grall wrote:
On 29/09/2020 14:37, Jan Beulich wrote:
On 29.09.2020 15:03, Julien Grall wrote:
I am thinking that it may be easier to hold the write lock when doing
the update.
... perhaps this is indeed better. I ha
Since commit c330fb1ddc0a ("XEN uses irqdesc::irq_data_common::handler_data to
store a per interrupt XEN data pointer which contains XEN specific
information.")
Xen is using the chip_data pointer for storing IRQ specific data. When
running as a HVM domain this can result in problems for legacy IR
flight 155062 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155062/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-xsm 12 guest-start fail REGR. vs. 154358
test-amd64-amd
Hi all,
I would like to bring up a discussion about a Xen-checker tool, the
development of which has been temporarily suspended. The idea of this
tool is to use the clang-format approach as a base for Xen ‘checkpatch’
process. The new tool consists of modified clang-format binary and
modified clan
Hi Alex,
On 29/09/2020 22:11, Alex Bennée wrote:
Julien Grall writes:
Hi Alex,
On 29/09/2020 16:29, Alex Bennée wrote:
Julien Grall writes:
From: Julien Grall
Hi all,
Xen on ARM has been broken for quite a while on ACPI systems. This
series aims to fix it.
Unfortunately I don't hav
On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote:
> Am 30.09.20 um 10:19 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 30.09.20 um 10:05 schrieb Christian König:
> > > Am 29.09.20 um 19:49 schrieb Thomas Zimmermann:
> > > > Hi Christian
> > > >
> > > > Am 29.09.20 um 17:35 schrieb C
On 30.09.2020 11:18, Anastasiia Lukianenko wrote:
> I would like to know your opinion on the following coding style cases.
> Which option do you think is correct?
> 1) Function prototype when the string length is longer than the allowed
> one
> -static int __init
> -acpi_parse_gic_cpu_interface(str
On 30.09.2020 10:52, Paul Durrant wrote:
> Looking again, given that both send_guest_vcpu_virq() and
> send_guest_global_virq() (rightly) hold the evtchn lock before
> calling evtchn_port_set_pending() I think you could do away with
> the virq lock by adding checks in those functions to verify
> ev
> On Sep 30, 2020, at 10:57 AM, Jan Beulich wrote:
>
> On 30.09.2020 11:18, Anastasiia Lukianenko wrote:
>> I would like to know your opinion on the following coding style cases.
>> Which option do you think is correct?
>> 1) Function prototype when the string length is longer than the allowed
flight 155131 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155131/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 5dba8c2f23049aa68b777a9e7e9f76c12dd00012
baseline version:
xen 2785
(Removing the x86 folks from the CC list)
Hi André,
On 30/09/2020 00:39, André Przywara wrote:
On 29/09/2020 22:11, Alex Bennée wrote:
Hi,
Julien Grall writes:
Hi Alex,
On 29/09/2020 16:29, Alex Bennée wrote:
Julien Grall writes:
From: Julien Grall
Hi all,
Xen on ARM has been bro
Julien Grall writes:
> Hi Alex,
>
> On 29/09/2020 22:11, Alex Bennée wrote:
>>
>> Julien Grall writes:
>>
>>> Hi Alex,
>>>
>>> On 29/09/2020 16:29, Alex Bennée wrote:
Julien Grall writes:
> From: Julien Grall
>
> Hi all,
>
> Xen on ARM has been broken for
EOIs are always executed in guest vCPU context, so there's no reason to
pass a vCPU parameter around as can be fetched from current.
While there make the vector parameter of both callbacks unsigned int.
No functional change intended.
Suggested-by: Paul Durrant
Signed-off-by: Roger Pau Monné
--
Remove the unconditional call to hvm_dpci_msi_eoi in vlapic_handle_EOI
and instead use the newly introduced EOI callback mechanism in order
to register a callback for MSI vectors injected from passed through
devices.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/hvm/vlapic.c| 2 --
xen/ar
Add a new vlapic_set_irq_callback helper in order to inject a vector
and set a callback to be executed when the guest performs the end of
interrupt acknowledgment.
Such functionality will be used to migrate the current ad hoc handling
done in vlapic_handle_EOI for the vectors that require some log
Such callbacks will be executed once a EOI is performed by the guest,
regardless of whether the interrupts are injected from the vIO-APIC or
the vPIC, as ISA IRQs are translated to GSIs and then the
corresponding callback is executed at EOI.
The vIO-APIC infrastructure for handling EOIs is build o
Hello,
The following series introduces EOI callbacks and switches a number of
subsystems to use them. The first one is vmsi and dpci, which are quite
straight forward to switch since they used to open code hooks in the EOI
handlers.
Finally HVM virtual timers are also switched to a different mode
Currently vPT relies on timers being assigned to a vCPU and performing
checks on every return to HVM guest in order to check if an interrupt
from a vPT timer assigned to the vCPU is currently being injected.
This model doesn't work properly since the interrupt destination vCPU
of a vPT timer can b
EOIs are always executed in guest vCPU context, so there's no reason to
pass a domain parameter around as can be fetched from current->domain.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- New in this version.
---
xen/arch/x86/hvm/vioapic.c | 2 +-
xen
Switch the dpci GSI EOI callback hooks to use the newly introduced
generic callback functionality, and remove the custom dpci calls found
on the vPIC and vIO-APIC implementations.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- New in this version.
---
xen/arch/x86/hvm/vioapic.c| 7
This is code movement in order to simply further changes.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- New in this version.
---
xen/drivers/passthrough/io.c | 172 +--
1 file changed, 86 insertions(+), 86 deletions(-)
di
Switch the emulated IO-APIC code to use the local APIC EOI callback
mechanism. This allows to remove the last hardcoded callback from
vlapic_handle_EOI. Removing the hardcoded vIO-APIC callback also
allows to getting rid of setting the EOI exit bitmap based on the
triggering mode, as now all users
No longer add vPT timers to lists on specific vCPUs, since there's no
need anymore to check if timer interrupts have been injected on return
to HVM guest.
Such change allows to get rid of virtual timers vCPU migration, and
also cleanup some of the virtual timers fields that are no longer
required.
Introduce a per virtual timer lock that replaces the existing per-vCPU
and per-domain vPT locks. Since virtual timers are no longer assigned
or migrated between vCPUs the locking can be simplified to a
in-structure spinlock that protects all the fields.
This requires introducing a helper to initia
Hi Alex,
On 30/09/2020 11:38, Alex Bennée wrote:
Julien Grall writes:
Hi Alex,
On 29/09/2020 22:11, Alex Bennée wrote:
Julien Grall writes:
Hi Alex,
On 29/09/2020 16:29, Alex Bennée wrote:
Julien Grall writes:
From: Julien Grall
Hi all,
Xen on ARM has been broken for quite a w
On Wednesday, September 30, 2020 2:49 AM, Jan Beulich wrote:
> On 29.09.2020 20:17, Trammell Hudson wrote:
> > - if ( dtbfile.addr && dtbfile.size )
> > - if ( dtbfile.need_to_free )
> > efi_bs->FreePages(dtbfile.addr, PFN_UP(dtbfile.size));
> > if ( memmap )
> > efi_bs->FreePool(m
> -Original Message-
> From: Roger Pau Monne
> Sent: 30 September 2020 11:41
> To: xen-devel@lists.xenproject.org
> Cc: Roger Pau Monne ; Jan Beulich ;
> Andrew Cooper
> ; Wei Liu ; Paul Durrant
> ; Paul Durrant
>
> Subject: [PATCH v2 01/11] x86/hvm: drop vcpu parameter from vlapic EOI
> -Original Message-
> From: Roger Pau Monne
> Sent: 30 September 2020 11:41
> To: xen-devel@lists.xenproject.org
> Cc: Roger Pau Monne ; Jan Beulich ;
> Andrew Cooper
> ; Wei Liu ; Paul Durrant
>
> Subject: [PATCH v2 02/11] x86/hvm: drop domain parameter from vioapic/vpic
> EOI callba
flight 155128 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155128/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Wed, Sep 30, 2020 at 08:41:48AM +0200, Thomas Gleixner wrote:
> On Tue, Sep 29 2020 at 16:03, Megha Dey wrote:
> > On 8/26/2020 4:16 AM, Thomas Gleixner wrote:
> >> #9 is obviously just for the folks interested in IMS
> >>
> >
> > I see that the tip tree (as of 9/29) has most of these patches bu
On Wed, Sep 23, 2020 at 04:57:31PM +0100, Paul Durrant wrote:
> From: Paul Durrant
>
> Currently a single watch on /local/domain/X/backend is registered by each
> QEMU process running in service domain X (where X is usually 0). The purpose
> of this watch is to ensure that QEMU is notified when t
> -Original Message-
> From: Xen-devel On Behalf Of Roger
> Pau Monne
> Sent: 30 September 2020 11:41
> To: xen-devel@lists.xenproject.org
> Cc: Roger Pau Monne ; Jan Beulich ;
> Andrew Cooper
> ; Wei Liu
> Subject: [PATCH v2 03/11] x86/vlapic: introduce an EOI callback mechanism
>
> A
> -Original Message-
> From: Roger Pau Monne
> Sent: 30 September 2020 11:41
> To: xen-devel@lists.xenproject.org
> Cc: Roger Pau Monne ; Jan Beulich ;
> Andrew Cooper
> ; Wei Liu ; Paul Durrant
>
> Subject: [PATCH v2 04/11] x86/vmsi: use the newly introduced EOI callbacks
>
> Remove t
This patch series adds support for bundling the xen.efi hypervisor,
the xen.cfg configuration file, the Linux kernel and initrd, as well
as the XSM, and architectural specific files into a single "unified"
EFI executable. This allows an administrator to update the components
independently without
This patch adds support for bundling the xen.efi hypervisor, the xen.cfg
configuration file, the Linux kernel and initrd, as well as the XSM,
and architectural specific files into a single "unified" EFI executable.
This allows an administrator to update the components independently
without requirin
Add a separate function to display the address ranges used by
the files and call `efi_arch_handle_module()` on the modules.
Signed-off-by: Trammell Hudson
Acked-by: Jan Beulich
---
xen/common/efi/boot.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --
The config file, kernel, initrd, etc should only be freed if they
are allocated with the UEFI allocator. On x86 the ucode, and on
ARM the dtb, are also marked as need_to_free when allocated or
expanded.
This also fixes a memory leak in ARM fdt_increase_size() if there
is an error in building the
If a unified Xen image is used, then the bundled configuration,
Xen command line, dom0 kernel, and ramdisk are prefered over
any files listed in the config file or provided on the command line.
Unlike the shim based verification, the PE signature on a unified image
covers all of the Xen+config+ker
This patch wraps the EFI OutputString() method so that they can be
called with const arguments. The OutputString method does not modify
its argument, although the prototype is missing const, so it is necssary
to cast away the const when calling it.
It also updates callers of PrintStr/PrintErr to
On 30.09.20 11:16, Juergen Gross wrote:
> Since commit c330fb1ddc0a ("XEN uses irqdesc::irq_data_common::handler_data
> to store a per interrupt XEN data pointer which contains XEN specific
> information.")
> Xen is using the chip_data pointer for storing IRQ specific data. When
> running as a HV
> -Original Message-
> From: Xen-devel On Behalf Of Roger
> Pau Monne
> Sent: 30 September 2020 11:41
> To: xen-devel@lists.xenproject.org
> Cc: Roger Pau Monne ; Jan Beulich ;
> Andrew Cooper
> ; Wei Liu
> Subject: [PATCH v2 05/11] x86/vioapic: switch to use the EOI callback
> mechani
On 30.09.2020 14:00, Trammell Hudson wrote:
> This patch wraps the EFI OutputString() method so that they can be
> called with const arguments. The OutputString method does not modify
> its argument, although the prototype is missing const, so it is necssary
> to cast away the const when calling i
On Wednesday, September 30, 2020 8:15 AM, Jan Beulich wrote:
> On 30.09.2020 14:00, Trammell Hudson wrote:
> > This patch wraps the EFI OutputString() method so that they can be
> > called with const arguments. The OutputString method does not modify
> > its argument, although the prototype is mis
Am 30.09.20 um 11:47 schrieb Daniel Vetter:
On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote:
Am 30.09.20 um 10:19 schrieb Thomas Zimmermann:
Hi
Am 30.09.20 um 10:05 schrieb Christian König:
Am 29.09.20 um 19:49 schrieb Thomas Zimmermann:
Hi Christian
Am 29.09.20 um 17:35 sch
Hi Jason
On Mon, 2020-08-31 at 11:39 -0300, Jason Gunthorpe wrote:
> On Wed, Aug 26, 2020 at 01:16:52PM +0200, Thomas Gleixner wrote:
> > From: Thomas Gleixner
> >
> > Devices on the VMD bus use their own MSI irq domain, but it is not
> > distinguishable from regular PCI/MSI irq domains. This is
On Wed, Sep 30, 2020 at 2:34 PM Christian König
wrote:
>
> Am 30.09.20 um 11:47 schrieb Daniel Vetter:
> > On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote:
> >> Am 30.09.20 um 10:19 schrieb Thomas Zimmermann:
> >>> Hi
> >>>
> >>> Am 30.09.20 um 10:05 schrieb Christian König:
>
Define a specific criteria for how we determine what tools and
libraries to be compatible with. This will clarify issues such as,
"Should we continue to support Python 2.4" moving forward.
Note that CentOS 7 is set to stop receiving "normal" maintenance
updates in "Q4 2020"; assuming that 4.15 is
On Wed, Sep 30, 2020 at 12:45:30PM +, Derrick, Jonathan wrote:
> Hi Jason
>
> On Mon, 2020-08-31 at 11:39 -0300, Jason Gunthorpe wrote:
> > On Wed, Aug 26, 2020 at 01:16:52PM +0200, Thomas Gleixner wrote:
> > > From: Thomas Gleixner
> > >
> > > Devices on the VMD bus use their own MSI irq do
+Megha
On Wed, 2020-09-30 at 09:57 -0300, Jason Gunthorpe wrote:
> On Wed, Sep 30, 2020 at 12:45:30PM +, Derrick, Jonathan wrote:
> > Hi Jason
> >
> > On Mon, 2020-08-31 at 11:39 -0300, Jason Gunthorpe wrote:
> > > On Wed, Aug 26, 2020 at 01:16:52PM +0200, Thomas Gleixner wrote:
> > > > From:
On 30.09.2020 14:57, George Dunlap wrote:
> --- /dev/null
> +++ b/docs/policies/dependency-versions.rst
> @@ -0,0 +1,76 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +Build and runtime dependencies
> +==
> +
> +Xen depends on other programs and libraries to build and
flight 155066 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155066/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail
REGR. vs. 15171
On Wed, Sep 30, 2020 at 01:09:21PM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel On Behalf Of Roger
> > Pau Monne
> > Sent: 30 September 2020 11:41
> > To: xen-devel@lists.xenproject.org
> > Cc: Roger Pau Monne ; Jan Beulich
> > ; Andrew Cooper
> > ; Wei Liu
> >
> On Sep 30, 2020, at 2:11 PM, Jan Beulich wrote:
>
> On 30.09.2020 14:57, George Dunlap wrote:
>> --- /dev/null
>> +++ b/docs/policies/dependency-versions.rst
>> @@ -0,0 +1,76 @@
>> +.. SPDX-License-Identifier: CC-BY-4.0
>> +
>> +Build and runtime dependencies
>> +=
On Wed, Sep 30, 2020 at 12:41:08PM +0200, Roger Pau Monne wrote:
> Introduce a per virtual timer lock that replaces the existing per-vCPU
> and per-domain vPT locks. Since virtual timers are no longer assigned
> or migrated between vCPUs the locking can be simplified to a
> in-structure spinlock th
On Wed, Sep 30, 2020 at 12:57:31PM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 30 September 2020 11:41
> > To: xen-devel@lists.xenproject.org
> > Cc: Roger Pau Monne ; Jan Beulich
> > ; Andrew Cooper
> > ; Wei Liu ; Paul Durrant
> >
> > Subject:
On 30.09.2020 15:29, George Dunlap wrote:
> The list above was made by trying to make sense of the table in the link
> above (https://www.suse.com/lifecycle/). I think it’s important to have
> references such that the release manager can easily update this list every
> release. Do you think yo
Hi Julien
On 25.09.20 11:19, Paul Durrant wrote:
-Original Message-
From: Julien Grall
Sent: 24 September 2020 19:01
To: Oleksandr Tyshchenko ; xen-devel@lists.xenproject.org
Cc: Oleksandr Tyshchenko ; Andrew Cooper
;
George Dunlap ; Ian Jackson
; Jan Beulich
; Stefano Stabellini ;
Nested virt is still experimental, and requires explicitly opting in to at
domain create time. The VMX/SVM features should not be visible by default.
Also correct them from all HVM guests, to just HAP-enabled guests. This has
been the restriction for SVM right from the outset (c/s e006a0e0aaa),
The sole caller has been removed.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
tools/flask/policy/modules/xen.if | 2 +-
xen/include/xsm/dummy.h | 6 --
xen/include/xsm/xsm.h | 6 --
xen/xsm/dummy.c
The use of the ternary operator serves only to obfuscate the code. Rewrite it
in more simple terms, avoiding the need to conditionally OR zero into the
flags.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Anthony PERARD
---
tools/libxl/libxl_create.c | 10 ++
1 fil
Previously, migration was reordered so the CPUID data was available before
register state. nestedhvm_enabled() has recently been made accurate for the
entire lifetime of the domain.
Therefore, we can drop the bodge in hvm_cr4_guest_valid_bits() which existed
previously to tolerate a guests' CR4 b
With XEN_DOMCTL_CDF_nested_virt now passed properly to domain_create(),
reimplement nestedhvm_enabled() to use the property which is fixed for the
lifetime of the domain.
This makes the call to nestedhvm_vcpu_initialise() from hvm_vcpu_initialise()
no longer dead. It became logically dead with th
Nested Virt is the final special case in legacy CPUID handling. Pass the
(poorly named) nested_hvm setting down into xc_cpuid_apply_policy() to break
the semantic dependency on HVM_PARAM_NESTEDHVM.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Anthony
Introduce some local variables to make the resulting logic easier to follow.
Join the two IOMMU checks in sanitise_domain_config(). Tweak some of the
terminology for better accuracy.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
x
Like other major areas of functionality, nested virt (or not) needs to be
known at domain creation time for sensible CPUID handling, and wants to be
known this early for sensible infrastructure handling in Xen.
Introduce XEN_DOMCTL_CDF_nested_virt and modify libxl to set it appropriately
when crea
This is the final bit of untangling for existing CPUID handling, as well as
the logical next step in nested-virt work to start making it usable.
Patch 4 was previously posted in isolation. It is unchanged in this series.
Andrew Cooper (8):
tools/libxl: Simplify DOMCTL_CDF_ flags handling in li
On 9/30/20 5:16 AM, Juergen Gross wrote:
> Since commit c330fb1ddc0a ("XEN uses irqdesc::irq_data_common::handler_data
> to store a per interrupt XEN data pointer which contains XEN specific
> information.")
> Xen is using the chip_data pointer for storing IRQ specific data. When
> running as a
On 9/29/20 10:14 PM, Souptick Joarder wrote:
> On Tue, Sep 29, 2020 at 6:00 PM wrote:
>>
>>
>> On 9/29/20 8:09 AM, Souptick Joarder wrote:
>>> On Fri, Sep 11, 2020 at 8:12 PM wrote:
On 9/6/20 2:51 AM, Souptick Joarder wrote:
> In 2019, we introduced pin_user_pages*() and now we a
On 9/18/20 11:17 PM, Jing Xiangfeng wrote:
> After commit 9f51c05dc41a ("pvcalls-front: Avoid
> get_free_pages(GFP_KERNEL) under spinlock"), the variable ret is being
> initialized with '-ENOMEM' that is meaningless. So remove it.
>
> Signed-off-by: Jing Xiangfeng
Applied to for-linus-5.10
On 9/25/20 10:07 AM, Juergen Gross wrote:
> When running as Xen dom0 the kernel isn't responsible for selecting the
> error handling mode, this should be handled by the hypervisor.
>
> So disable setting FF mode when running as Xen pv guest. Not doing so
> might result in boot splats like:
>
> [
On 9/27/20 1:28 PM, Hui Su wrote:
> arch/x86: fix some typos in xen_pagetable_p2m_free():
> s/Fortunatly/Fortunately
>
> Signed-off-by: Hui Su
Applied to for-linus-5.10 (after rewording slightly the commit message)
-boris
On 19.08.2020 18:51, Don Slutz wrote:
> Since I need to change xen/arch/x86/hvm/Makefile; also add
> a newline at end of file.
Should this have been removed?
Also please update / trim your Cc list. I've dropped / replaced a
number of entries which I'm sure would have bounced.
> --- a/xen/arch/x8
On Thu, Sep 24, 2020 at 02:10:24PM +0100, Paul Durrant wrote:
> These domctls provide a mechanism to get and set domain context from
> the toolstack.
>
> Signed-off-by: Paul Durrant
> Reviewed-by: Julien Grall
Acked-by: Wei Liu
On Thu, Sep 24, 2020 at 02:10:25PM +0100, Paul Durrant wrote:
> This tool is analogous to 'xen-hvmctx' which presents HVM context.
> Subsequent patches will add 'dump' functions when new records are
> introduced.
>
> Signed-off-by: Paul Durrant
> Acked-by: Ian Jackson
Acked-by: Wei Liu
On Thu, Sep 24, 2020 at 02:10:26PM +0100, Paul Durrant wrote:
> From: Paul Durrant
>
> The STATIC_DATA_END, X86_CPUID_POLICY and X86_MSR_POLICY record types have
> sections explaining what they are but their values are not defined. Indeed
> their values are defined as "Reserved for future mandato
On Thu, Sep 24, 2020 at 02:10:27PM +0100, Paul Durrant wrote:
> From: Paul Durrant
>
> A new 'domain context' framework was recently introduced to facilitate
> transfer of state for both PV and HVM guests. Hence this patch mandates the
> presence of a new DOMAIN_CONTEXT record in version 4 of the
On Thu, Sep 24, 2020 at 02:10:28PM +0100, Paul Durrant wrote:
> From: Paul Durrant
>
> ... and update xen-domctx to dump some information describing the record.
>
> NOTE: Processing of the content during restore is currently limited to
> PV domains, and matches processing of the PV-only SH
On Thu, Sep 24, 2020 at 02:10:29PM +0100, Paul Durrant wrote:
> From: Paul Durrant
>
> ... and update xen-domctx to dump some information describing the record.
>
> NOTE: Whilst the record definition is x86 specific, it is visible directly
> in the common header as context record numbers s
On Thu, Sep 24, 2020 at 02:10:30PM +0100, Paul Durrant wrote:
> From: Paul Durrant
>
> ... and bump the version.
>
> This patch implements version 4 of the migration stream by adding the code
> necessary to save and restore DOMAIN_CONTEXT records, and removing the code
> to save the SHARED_INFO
On Tue, Sep 29, 2020 at 03:43:30PM +0300, Joonas Lahtinen wrote:
> Hmm, those are both committed after our last -next pull request, so they
> would normally only target next merge window. drm-next closes the merge
> window around -rc5 already.
>
> But, in this specific case those are both Fixes: p
1 - 100 of 150 matches
Mail list logo
