flight 120990 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120990/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not suc
flight 120984 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120984/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail REGR. vs. 118294
build-i386-pvops
flight 120974 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120974/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 broken in 120908
test-xtf-amd64-amd64-2 50 x
Hi Andre,
On 03/21/2018 04:32 PM, Andre Przywara wrote:
Tell Xen whether a particular VCPU has an IRQ that needs handling
in the guest. This is used to decide whether a VCPU is runnable or
if a hypercall should be preempted to let the guest handle the IRQ.
This is based on Linux commit 90eee56c
Hi Andre,
On 03/21/2018 04:32 PM, Andre Przywara wrote:
+/*
+ * If a hardware mapped IRQ has been handled for good, we need to
+ * clear the _IRQ_INPROGRESS bit to allow handling of new IRQs.
+ */
+if ( irq->hw && !lr_val.active && !lr_val.pending )
+
flight 120991 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120991/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf df67a480eb81821ba21ad6909e2fda287e745834
baseline version:
ovmf ae38c9765a27264ecea03
flight 120967 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120967/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
test-amd64-amd64-xl-pvhv2-amd 12
Hi Andre,
On 03/21/2018 04:32 PM, Andre Przywara wrote:
Implement the framework for syncing IRQs between our emulation and the
list registers, which represent the guest's view of IRQs.
This is done in vgic_sync_from_lrs() and vgic_sync_to_lrs(), which
get called on guest entry and exit, respecti
Hi Andre,
On 03/21/2018 04:32 PM, Andre Przywara wrote:
This pulls in Linux' list_sort.c, which is a merge sort implementation
s/Linux'/Linux's/ ?
for linked lists. Apart from adding a full featured license header and
adjusting the #include file, nothing has been changed in this code.
Define
Hi Andre,
On 03/21/2018 04:32 PM, Andre Przywara wrote:
The new VGIC implementation centers around a struct vgic_irq instance
per virtual IRQ.
Provide a function to retrieve the right instance for a given IRQ
number and (in case of private interrupts) the right VCPU.
This also includes the corre
On 03/21/2018 04:32 PM, Andre Przywara wrote:
The event channel IRQ has level triggered semantics, however the current
VGIC treats everything as edge triggered.
To correctly process those IRQs, we have to lower the (virtual) IRQ line
at some point in time, depending on whether ther interrupt co
Hi Andre,
On 03/21/2018 04:32 PM, Andre Przywara wrote:
The ARM Generic Timer uses a level-sensitive interrupt semantic. We
easily catch when the line goes high, as this triggers the hardware IRQ.
However we also have to keep track of when the line lowers, as the
emulation depends on it: Upon en
Hi Andre,
On 03/21/2018 04:31 PM, Andre Przywara wrote:
When playing around with hardware mapped, level triggered virtual IRQs,
there is the need to explicitly set the active or pending state of an
interrupt at some point.
To prepare the GIC for that, we introduce a set_active_state() and a
set_
Hi Andre,
On 03/21/2018 04:31 PM, Andre Przywara wrote:
The enum gic_version at the moment just contains GIC_V2 and GIC_V3,
where GIC_V2 happens to map to 0. So without having initialised a
variable of that type, we will read back GIC_V2 (when allocated with zeroing
the memory).
To prevent ambig
On 03/21/2018 10:58 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], capable of running as a Weston client
or DRM maste
On Wed, 21 Mar 2018 17:06:28 +
Paul Durrant wrote:
[...]
>> Well, this might work actually. Although the overall scenario will be
>> overcomplicated a bit for _PCI_CONFIG ioreqs. Here is how it will
>> look:
>>
>> QEMU receives PCIEXBAR update -> calls the new dmop to tell Xen new
>> MMCONFIG
flight 121043 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121043/
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
flight 120977 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120977/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail in
120911 pass in 120977
test-armhf-armh
On 03/21/2018 02:11 PM, Jan Beulich wrote:
On 21.03.18 at 05:47, wrote:
From: Wei Liu
In a follow-up patches, some callers will be switched to pass
INVALID_MFN instead of zero for non-present mappings. So skip
incrementing mfn if it is not a valid one.
Signed-off-by: Wei Liu
Signed-off-by
On Wed, 21 Mar 2018 17:15:04 +
Roger Pau Monné wrote:
[...]
>> Above scenario makes it obvious that at least for QEMU the MMIO->PCI
>> conf translation is a redundant step. Why not to allow specifying
>> for DM whether it prefers to receive MMCONFIG accesses as native
>> (MMIO ones) or as tran
flight 120965 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120965/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 120116
test-xtf-amd64-
On 03/15/2018 10:22 AM, Joao Martins wrote:
> All uploaded PM data from non-dom0 CPUs takes the info from vCPU 0 and
> changing only the acpi_id. For processors which P-state coordination type
> is HW_ALL (0xFD) it is OK to upload bogus P-state dependency information
> (_PSD), because Xen will igno
On 03/19/2018 12:58 PM, Jason Andryuk wrote:
> Commit 2cc42bac1c79 ("x86-64/Xen: eliminate W+X mappings") introduced a
> call to get_cpu_cap, which is fstack-protected. This is works on x86-64
> as commit 4f277295e54c ("x86/xen: init %gs very early to avoid page
> faults with stack protector") ens
On 03/14/2018 10:43 PM, Simon Gaiser wrote:
> Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple
> concurrent xenstore accesses") made a subtle change to the semantic of
> xenbus_dev_request_and_reply() and xenbus_transaction_end().
>
> Before on an error response to XS_TRANSACTION_END
On 28/02/2018 16:09, Sergey Dyasli wrote:
> diff --git a/xen/include/asm-x86/msr.h b/xen/include/asm-x86/msr.h
> index 419ab6f8a7..4747572871 100644
> --- a/xen/include/asm-x86/msr.h
> +++ b/xen/include/asm-x86/msr.h
> @@ -606,6 +606,9 @@ int init_vcpu_msr_policy(struct vcpu *v);
> int guest_rdmsr
On 28/02/2018 16:09, Sergey Dyasli wrote:
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index aa0505036b..4856ad7c24 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1699,7 +1699,7 @@ static void vmx_update_guest_cr(struct vcpu *v,
> uns
On 28/02/2018 16:09, Sergey Dyasli wrote:
> Currently, when nested virt is enabled, the set of L1 VMX features
> is fixed and calculated by nvmx_msr_read_intercept() as an intersection
> between the full set of Xen's supported L1 VMX features, the set of
> actual H/W features and, for MSR_IA32_VMX_
flight 120981 rumprun real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120981/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumprun 6 rumprun-buildfail REGR. vs. 106754
build-i386-rumprun
On 28/02/2018 16:09, Sergey Dyasli wrote:
> @@ -474,6 +505,10 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t
> val)
> break;
> }
>
> +case MSR_IA32_VMX_BASIC ... MSR_IA32_VMX_VMFUNC:
> +/* None of these MSRs are writeable. */
> +goto gp_fault;
There
flight 121036 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121036/
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 28/02/18 16:09, Sergey Dyasli wrote:
> New definitions provide a convenient way of accessing contents of
> VMX MSRs. They are separated into 5 logical blocks based on the
> availability conditions of MSRs in the each block:
>
> 1. vmx: [VMX_BASIC, VMX_VMCS_ENUM]
> 2. VMX_PROCBASED_CTLS2
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-win7-amd64
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditi
On 3/21/18 11:58 AM, Wei Liu wrote:
> On Wed, Mar 21, 2018 at 11:09:13AM -0500, Doug Goldstein wrote:
>> On 3/21/18 6:11 AM, George Dunlap wrote:
>>> On 03/21/2018 03:01 AM, Doug Goldstein wrote:
Created a new section just called 'CI' since this is adding GitLab CI
and still leaving the o
On Wed, Mar 21, 2018 at 02:42:11PM +, Roger Pau Monne wrote:
> This will lead to writing a wrong module command line physical memory
> address if no command line is actually provided.
>
> This hasn't caused problems so far because hvmloader is the only
> consumer of the modules command line, a
On Wed, Mar 21, 2018 at 02:42:10PM +, Roger Pau Monne wrote:
> The start_info size calculated in bootlate_hvm is wrong. It should use
> HVMLOADER_MODULE_MAX_COUNT instead of dom->num_modules and it doesn't
> take into account the size of the modules command line.
>
> This is not a problem so f
On 21/03/18 05:46, Juergen Gross wrote:
> On 20/03/18 18:22, Andrew Cooper wrote:
>> On 20/03/18 16:58, Jan Beulich wrote:
>> On 19.03.18 at 20:13, wrote:
It is not entirely clear why this interlock was introduced in c/s 8cbb5278e
"x86/AMD: Add support for AMD's OSVW feature in guest
On 03/21/2018 01:49 PM, Wei Liu wrote:
> On Tue, Mar 20, 2018 at 09:50:50AM -0700, Maran Wilson wrote:
>> case LIBXL_DOMAIN_TYPE_PV:
>> -ret = libxl__build_pv(gc, domid, info, state);
>> +ret = libxl__build_pv(gc, domid, d_config, info, state);
>> if (ret)
>>
On Wed, Mar 21, 2018 at 04:47:22AM +, Julien Grall wrote:
> From: Wei Liu
>
> In a follow-up patches, some callers will be switched to pass
s/patches/patch/
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mai
On 03/21/2018 10:18 AM, Roger Pau Monné wrote:
> On Wed, Mar 21, 2018 at 09:37:09AM -0400, Boris Ostrovsky wrote:
>> On 03/21/2018 06:07 AM, Roger Pau Monné wrote:
>>> On Tue, Mar 20, 2018 at 09:50:52AM -0700, Maran Wilson wrote:
From: Boris Ostrovsky
Signed-off-by: Boris Ostrovsky
On Tue, Mar 20, 2018 at 09:50:50AM -0700, Maran Wilson wrote:
> case LIBXL_DOMAIN_TYPE_PV:
> -ret = libxl__build_pv(gc, domid, info, state);
> +ret = libxl__build_pv(gc, domid, d_config, info, state);
> if (ret)
> goto out;
>
> diff --git a/tools/libxl/l
On Mon, Mar 19, 2018 at 07:13:50PM +, Andrew Cooper wrote:
> XEN_DOMCTL_set_gnttab_limits is a fairly new hypercall, and is strictly
> mandatory. Adding support for it introduced a state where a domain has a
> mostly un-constructed grant table, and there were cases where mis-ordering of
> tool
On Mon, Mar 19, 2018 at 07:13:51PM +, Andrew Cooper wrote:
> XEN_DOMCTL_max_vcpus is a mandatory hypercall, but nothing actually prevents a
> toolstack from unpausing a domain with no vcpus.
>
> Originally, d->vcpus[] was an embedded array in struct domain, but c/s
> fb442e217 "x86_64: allow m
On Wed, 21 Mar 2018 14:54:16 +
Paul Durrant wrote:
>> -Original Message-
>> From: Alexey G [mailto:x19...@gmail.com]
>> Sent: 21 March 2018 14:26
>> To: Roger Pau Monne
>> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
>> ; Ian Jackson ;
>> Jan Beulich ; Wei Liu ; Paul
>> Durrant
On Mon, Mar 19, 2018 at 07:13:49PM +, Andrew Cooper wrote:
> set_max_evtchn is somewhat weird. It was introduced with the event_fifo work,
> but has never been used. Still, it is a bounding on resources consumed by the
> event channel infrastructure, and should be part of createdomain, rather
On Mon, Mar 19, 2018 at 07:13:48PM +, Andrew Cooper wrote:
> In future patches, the structure will be extended with further information,
> and this is far cleaner than adding extra parameters.
>
> The python stubs are the only user which passes NULL for the existing config
> option (which is a
On 21/03/18 16:18, Roger Pau Monné wrote:
> On Mon, Mar 19, 2018 at 07:13:41PM +, Andrew Cooper wrote:
>> xc_config is only used by xc_domain_create(), but by calling
>> libxl__arch_domain_{prepare,save}_config() we clobber the real settings with
>> the default settings.
>>
>> Move all data and
On Mon, Mar 19, 2018 at 07:13:42PM +, Andrew Cooper wrote:
> This is a tools only hypercall so fine to change. Altering the name avoids
> having confusing code such as config->config all over the hypervisor and
> toolstack.
>
> Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
__
On Mon, Mar 19, 2018 at 07:13:41PM +, Andrew Cooper wrote:
> xc_config is only used by xc_domain_create(), but by calling
> libxl__arch_domain_{prepare,save}_config() we clobber the real settings with
> the default settings.
>
> Move all data and calls relating to xc_domain_create() into the p
On Mon, Mar 19, 2018 at 07:13:40PM +, Andrew Cooper wrote:
> The data it stores is initialised and exclusively used within
> libxl__domain_make(), with the important details written back elsewhere by
> libxl__arch_domain_save_config(). Prepare xc_config on libxl__domain_make()'s
> stack, and d
On Fri, Mar 16, 2018 at 02:06:39PM +, Andrew Cooper wrote:
> The data it stores is initialised and exclusively used within
> libxl__domain_make(), with the important details written back elsewhere by
> libxl__arch_domain_save_config(). Prepare xc_config on libxl__domain_make()'s
> stack, and d
On Thu, Mar 22, 2018 at 02:56:56AM +1000, Alexey G wrote:
> On Wed, 21 Mar 2018 15:20:17 +
> Roger Pau Monné wrote:
>
> >On Thu, Mar 22, 2018 at 12:25:40AM +1000, Alexey G wrote:
> >> 8. As these MMCONFIG PCI conf reads occur out of context (just
> >> address/len/data without any emulated dev
On Fri, Mar 16, 2018 at 11:04:22PM +0530, Amit Singh Tomar wrote:
> diff --git a/xen/drivers/char/mvebu-uart.c b/xen/drivers/char/mvebu-uart.c
> new file mode 100644
> index 000..c88d5e7
> --- /dev/null
> +++ b/xen/drivers/char/mvebu-uart.c
> @@ -0,0 +1,260 @@
> +/*
> + * xen/drivers/char/mvebu
On Wed, Mar 21, 2018 at 04:27:43PM +, Wei Liu wrote:
> On Tue, Mar 20, 2018 at 09:11:10AM +, Roger Pau Monné wrote:
> > On Tue, Mar 20, 2018 at 08:11:49AM +1000, Alexey G wrote:
> > > On Mon, 19 Mar 2018 17:01:18 +
> > > Roger Pau Monné wrote:
> > >
> > > >On Tue, Mar 13, 2018 at 04:3
> -Original Message-
> From: Alexey G [mailto:x19...@gmail.com]
> Sent: 21 March 2018 16:57
> To: Roger Pau Monne
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Ian Jackson ; Jan
> Beulich ; Wei Liu ; Paul Durrant
> ; Anthony Perard ;
> Stefano Stabellini
> Subject: Re: [Xen-deve
>>> On 21.03.18 at 17:32, wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -44,6 +44,9 @@ config HAS_GDBSX
> config HAS_IOPORTS
> bool
>
> +config NEEDS_LIST_SORT
> +bool
> +
> config HAS_BUILD_ID
> string
> option env="XEN_HAS_BUILD_ID"
Please look
On Wed, Mar 21, 2018 at 09:46:21AM -0700, Maran Wilson wrote:
> On 3/21/2018 2:40 AM, Juergen Gross wrote:
> > On 21/03/18 10:28, Roger Pau Monné wrote:
> > > On Tue, Mar 20, 2018 at 09:48:56AM -0700, Maran Wilson wrote:
> > > > +/*
> > > >* C representation of the x86/HVM start info layout.
>
On Wed, Mar 21, 2018 at 11:09:13AM -0500, Doug Goldstein wrote:
> On 3/21/18 6:11 AM, George Dunlap wrote:
> > On 03/21/2018 03:01 AM, Doug Goldstein wrote:
> >> Created a new section just called 'CI' since this is adding GitLab CI
> >> and still leaving the old Travis CI files around. This consoli
On Wed, 2018-03-21 at 15:24 +, George Dunlap wrote:
>
> If you're OK with those changes,
>
I am cool with every one of them.
> I can make them on check-in (as well as
> changing your email address)
>
And thanks for this as well,
Dario
--
<> (Raistlin Majere)
---
On Wed, 21 Mar 2018 15:20:17 +
Roger Pau Monné wrote:
>On Thu, Mar 22, 2018 at 12:25:40AM +1000, Alexey G wrote:
>> Roger, Paul,
>>
>> Here is what you suggest, just to clarify:
>>
>> 1. Add to Xen a new hypercall (+corresponding dmop) so QEMU can tell
>> Xen where QEMU emulates machine's M
>>> On 21.03.18 at 17:00, wrote:
> On Mi, 2018-03-21 at 08:57 -0600, Jan Beulich wrote:
>> >
>> > >
>> > > >
>> > > > On 21.03.18 at 15:47, wrote:
>> > --- a/xen/include/asm-x86/hvm/hvm.h
>> > +++ b/xen/include/asm-x86/hvm/hvm.h
>> > @@ -209,6 +209,8 @@ struct hvm_function_table {
>> >
On Wed, Mar 14, 2018 at 03:36:08PM +0100, Marek Marczykowski-Górecki wrote:
> When LIBXL_SUSPEND_NO_SAVE flag is set, no savefile will be written, but
> the domain will still be suspended (but not destroyed). The main reason
> for this functionality is to suspend the host while some domains are
> r
On Wed, Mar 14, 2018 at 10:14:03AM -0700, Joe Jin wrote:
> xenbaked.c -> dump_stats(), run_time = time(&end_time) - time(&start_time),
> time() returns the value in seconds. If one cancels xenmon.py immediately
> after started, run_time can be zero, and then xenbaked will hit divide by
> zero fault
On 21/03/18 17:46, Maran Wilson wrote:
> On 3/21/2018 2:40 AM, Juergen Gross wrote:
>> On 21/03/18 10:28, Roger Pau Monné wrote:
>>> On Tue, Mar 20, 2018 at 09:48:56AM -0700, Maran Wilson wrote:
+/*
* C representation of the x86/HVM start info layout.
*
* The canonical
On Wed, Mar 14, 2018 at 01:27:37PM +, Julien Grall wrote:
> Hi,
>
> On 03/14/2018 12:32 PM, Wei Liu wrote:
> > Gcc with -O3 failed to spot the loop to initialise p2m_size runs at
> > least once.
>
> Aside, Andrew's comment the patch looks okay. But I am wondering why we need
> to allocate p2m
On 3/21/2018 2:40 AM, Juergen Gross wrote:
On 21/03/18 10:28, Roger Pau Monné wrote:
On Tue, Mar 20, 2018 at 09:48:56AM -0700, Maran Wilson wrote:
+/*
* C representation of the x86/HVM start info layout.
*
* The canonical definition of this layout is above, this is just a way to
@@ -86
On Mon, Mar 19, 2018 at 07:13:48PM +, Andrew Cooper wrote:
> In future patches, the structure will be extended with further information,
> and this is far cleaner than adding extra parameters.
>
> The python stubs are the only user which passes NULL for the existing config
> option (which is a
On Tue, Mar 20, 2018 at 01:05:32AM +1000, Alexey G wrote:
> On Tue, 13 Mar 2018 04:33:54 +1000
> Alexey Gerasimenko wrote:
>
> >Current Xen/QEMU method to control Xen Platform device is a bit odd --
> >changing 'xen_platform_device' option value actually modifies QEMU
> >emulated machine type, na
On Wed, 21 Mar 2018, Julien Grall wrote:
> Commit 5cb00d1 "ARM: GIC: extend LR read/write functions to cover EOI
> and source" extended gic_lr to cover the source. The new field was only
> set for SGIs interrupt in the read function. However, the write function
> is writing the field unconditionall
On Tue, Mar 20, 2018 at 09:11:10AM +, Roger Pau Monné wrote:
> On Tue, Mar 20, 2018 at 08:11:49AM +1000, Alexey G wrote:
> > On Mon, 19 Mar 2018 17:01:18 +
> > Roger Pau Monné wrote:
> >
> > >On Tue, Mar 13, 2018 at 04:33:53AM +1000, Alexey Gerasimenko wrote:
> > >> Provide a new domain c
On Tue, Mar 20, 2018 at 08:11:49AM +1000, Alexey G wrote:
> >> if (b_info->u.hvm.mmio_hole_memkb) {
> >> uint64_t max_ram_below_4g = (1ULL << 32) -
> >> diff --git a/tools/libxl/libxl_types.idl
> >> b/tools/libxl/libxl_types.idl index 35038120ca..f3ef3cbdde 100644
> >> --- a/t
To find an unused virtual IRQ number Xen uses a scheme to track used
virtual IRQs.
Implement this interface in the new VGIC to make the Xen core/arch code
happy.
This is actually somewhat VGIC agnostic, so is mostly a copy of the code
from the old VGIC. But it has to live in the VGIC files, so we c
When a VCPU moves to another CPU, we need to adjust the target affinity
of any hardware mapped vIRQs, to observe our "physical-follows-virtual"
policy.
Implement arch_move_irqs() to adjust the physical affinity of all hardware
mapped vIRQs targetting this VCPU.
Signed-off-by: Andre Przywara
Revie
The target register handlers are v2 emulation specific, so their
implementation lives entirely in vgic-mmio-v2.c.
We copy the old VGIC behaviour of assigning an IRQ to the first VCPU
set in the target mask instead of making it possibly pending on
multiple VCPUs.
We update the physical affinity of a
This patch implements the function which is called by Xen when it wants
to register the virtual GIC.
This also implements vgic_max_vcpus() for the new VGIC, which reports
back the maximum number of VCPUs a certain GIC model supports. Similar
to the counterpart in the "old" VGIC, we return some maxi
map_resources is the last initialization step needed before the first
VCPU is run. At that stage the code stores the MMIO base addresses used.
Also it registers the respective register frames with the MMIO framework.
This is based on Linux commit cbae53e663ea, written by Eric Auger.
Signed-off-by
The enum gic_version at the moment just contains GIC_V2 and GIC_V3,
where GIC_V2 happens to map to 0. So without having initialised a
variable of that type, we will read back GIC_V2 (when allocated with zeroing
the memory).
To prevent ambiguities and to give an explicitly uninitialised state, add
a
Adds the sorting function to cover the case where you have more IRQs
to consider than you have LRs. We consider their priorities.
This uses the new sort_list() implementation imported from Linux.
This is based on Linux commit 8e4447457965, written by Christoffer Dall.
Signed-off-by: Andre Przywar
Enable the VGIC operation by properly initialising the registers
in the hypervisor GIC interface.
This is based on Linux commit f7b6985cc3d0, written by Eric Auger.
Signed-off-by: Andre Przywara
Acked-by: Julien Grall
---
Changelog v2 ... v3:
- replace "1" with "true" in boolean parameter
Chan
This patch allocates and initializes the data structures used to model
the vgic distributor and virtual cpu interfaces. At that stage the
number of IRQs and number of virtual CPUs is frozen.
Implement the various functions that the Xen arch code is expecting to
call during domain and VCPU setup to
Now that we have both the old VGIC prepared to cope with a sibling and
the code for the new VGIC in place, lets add a Kconfig option to enable
the new code and wire it into the Xen build system.
This will add a compile time option to use either the "old" or the "new"
VGIC.
In the moment this is res
The pending register handlers are shared between the v2 and v3
emulation, so their implementation goes into vgic-mmio.c, to be easily
referenced from the v3 emulation as well later.
For level triggered interrupts the real line level is unaffected by
this write, so we keep this state separate and co
Triggering an IPI via this register is v2 specific, so the
implementation lives entirely in vgic-mmio-v2.c.
This is based on Linux commit 55cc01fb9004, written by Andre Przywara.
Signed-off-by: Andre Przywara
---
Changelog v2 ... v3:
- fix target mask calculation
Changelog v1 ... v2:
- remove s
The ARM arch code requires an interrupt controller emulation to implement
vgic_clear_pending_irqs(), although it is suspected that it is actually
not necessary. Go with a stub for now to make the linker happy.
Signed-off-by: Andre Przywara
Reviewed-by: Julien Grall
---
xen/arch/arm/vgic/vgic.c
When we dump guest state on the Xen console, we also print the state of
IRQs that are on a VCPU.
Add the code to dump the state of an IRQ handled by the new VGIC.
Signed-off-by: Andre Przywara
Acked-by: Julien Grall
---
xen/arch/arm/vgic/vgic.c | 25 +
1 file changed, 25
To synchronize level triggered interrupts which are mapped into a guest,
we need to update the virtual line level at certain points in time.
For a hardware mapped interrupt the GIC is the only place where we can
easily access this information.
Implement a gic_hw_operations member to return the pend
The event channel IRQ has level triggered semantics, however the current
VGIC treats everything as edge triggered.
To correctly process those IRQs, we have to lower the (virtual) IRQ line
at some point in time, depending on whether ther interrupt condition
still prevails.
Check the per-VCPU evtchn_
Processing maintenance interrupts and accessing the list registers
are dependent on the host's GIC version.
Introduce vgic-v2.c to contain GICv2 specific functions.
Implement the GICv2 specific code for syncing the emulation state
into the VGIC registers.
This also adds the hook to let Xen setup th
Create vgic-mmio-v2.c to describe GICv2 emulation specific handlers
using the initializer macros provided by the VGIC MMIO framework.
Provide a function to register the GICv2 distributor registers to
the Xen MMIO framework.
The actual handler functions are still stubs in this patch.
This is based
At the moment we allocate exactly one page for struct vcpu on ARM, also
have a check in place to prevent it growing beyond 4KB.
As the struct includes the state of all 32 private (per-VCPU) interrupts,
we are at 3840 bytes on arm64 at the moment already. Growing the per-IRQ
VGIC structure even slig
The Xen arch code traps system registers writes from the guest and will
relay anything GIC related to the VGIC.
Since this affects only GICv3 (which we don't yet emulate), provide a
stub implementation of vgic_emulate() for now.
Signed-off-by: Andre Przywara
Acked-by: Julien Grall
---
xen/arch/
As this register is v2 specific, its implementation lives entirely
in vgic-mmio-v2.c.
This register allows setting the source mask of an IPI.
This is based on Linux commit ed40213ef9b0, written by Andre Przywara.
Signed-off-by: Andre Przywara
Reviewed-by: Julien Grall
---
xen/arch/arm/vgic/vgi
The Xen core/arch code relies on two abstracted functions to inject an
event channel IRQ and to query its pending state.
Implement those to query the state of the new VGIC implementation.
Signed-off-by: Andre Przywara
Acked-by: Julien Grall
---
xen/arch/arm/vgic/vgic.c | 23
As the enable register handlers are shared between the v2 and v3
emulation, their implementation goes into vgic-mmio.c, to be easily
referenced from the v3 emulation as well later.
This introduces a vgic_sync_hardware_irq() function, which updates the
physical side of a hardware mapped virtual IRQ.
The config register handlers are shared between the v2 and v3 emulation,
so their implementation goes into vgic-mmio.c, to be easily referenced
from the v3 emulation as well later.
This is based on Linux commit 79717e4ac09c, written by Andre Przywara.
Signed-off-by: Andre Przywara
Reviewed-by: J
The ARM Generic Timer uses a level-sensitive interrupt semantic. We
easily catch when the line goes high, as this triggers the hardware IRQ.
However we also have to keep track of when the line lowers, as the
emulation depends on it: Upon entering the guest, the new VGIC will
*clear* the virtual int
The emulated ARM SBSA UART is using level triggered IRQ semantics,
however the current VGIC can only handle edge triggered IRQs, really.
Disable the existing workaround for this problem in case we have the
new VGIC in place, which can properly handle level triggered IRQs.
Signed-off-by: Andre Przy
This pulls in Linux' list_sort.c, which is a merge sort implementation
for linked lists. Apart from adding a full featured license header and
adjusting the #include file, nothing has been changed in this code.
Define a promptless Kconfig which configurations can select when they
need this code and
The VGIC supports virtual IRQs to be connected to a hardware IRQ, so
when a guest EOIs the virtual interrupt, it affects the state of that
corresponding interrupt on the hardware side at the same time.
Implement the interface that the Xen arch/core code expects to connect
the virtual and the physic
The active register handlers are shared between the v2 and v3 emulation,
so their implementation goes into vgic-mmio.c, to be easily referenced
from the v3 emulation as well later.
Since activation/deactivation of an interrupt may happen entirely in the
guest without it ever exiting, we need some e
The priority register handlers are shared between the v2 and v3 emulation,
so their implementation goes into vgic-mmio.c, to be easily referenced
from the v3 emulation as well later.
This is based on Linux commit 055658bf48fc, written by Andre Przywara.
Signed-off-by: Andre Przywara
Reviewed-by:
1 - 100 of 216 matches
Mail list logo
