On Fri, Mar 31, 2017 at 01:29:19PM +0200, Juergen Gross wrote:
> The handling of transactions in xenstored is rather clumsy today:
>
> - Each transaction in progress is keeping a local copy of the complete
> xenstore data base
> - A transaction will fail as soon as any node is being modified out
On 31/03/17 15:01, Wei Liu wrote:
> On Fri, Mar 31, 2017 at 02:11:46PM +0200, Juergen Gross wrote:
>> On 31/03/17 14:03, Wei Liu wrote:
>>> Another stupid question below.
>>>
>>> On Fri, Mar 31, 2017 at 01:29:19PM +0200, Juergen Gross wrote:
-struct changed_node
+/*
+ * Some n
On Fri, Mar 31, 2017 at 09:43:07AM -0400, Boris Ostrovsky wrote:
> On 03/31/2017 06:23 AM, Roger Pau Monné wrote:
> > On Thu, Mar 30, 2017 at 07:06:15PM -0400, Boris Ostrovsky wrote:
> >> In addition to 'device_model_version="none"' config option users can
> >> also use 'pvh=1' in xl configuration
On Fri, Mar 31, 2017 at 03:47:58PM +0200, Juergen Gross wrote:
> On 31/03/17 15:01, Wei Liu wrote:
> > On Fri, Mar 31, 2017 at 02:11:46PM +0200, Juergen Gross wrote:
> >> On 31/03/17 14:03, Wei Liu wrote:
> >>> Another stupid question below.
> >>>
> >>> On Fri, Mar 31, 2017 at 01:29:19PM +0200, Jue
Hi Wei,
Thanks for taking a look at this RFC. Responses/questions below...
Wei Liu writes:
> On Fri, Mar 31, 2017 at 11:24:24AM +0100, Punit Agrawal wrote:
>> populate_physmap() calls alloc_heap_pages() per requested extent. As
>> alloc_heap_pages() performs icache maintenance operations affect
flight 107030 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107030/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12 mig
On 03/31/2017 09:49 AM, Wei Liu wrote:
> On Fri, Mar 31, 2017 at 09:43:07AM -0400, Boris Ostrovsky wrote:
>> On 03/31/2017 06:23 AM, Roger Pau Monné wrote:
>>> On Thu, Mar 30, 2017 at 07:06:15PM -0400, Boris Ostrovsky wrote:
In addition to 'device_model_version="none"' config option users can
On 03/31/2017 06:14 AM, Juergen Gross wrote:
> For kdump to work correctly it needs the physical address of
> vmcoreinfo_note. When running as dom0 this means the virtual address
> has to be translated to the related machine address.
>
> paddr_vmcoreinfo_note() is meant to do the translation via
>
On Thu, Mar 30, 2017 at 07:42:48PM +0200, Gémes Géza wrote:
>
> > On Mon, Mar 27, 2017 at 09:28:14PM +0200, Gémes Géza wrote:
> > > Hi,
> > >
> > > Currently the xen build system has optional support for building a minios
> > > (+needed libraries and tools) based stubdom.
> > >
> > > What is you
Hi Wei,
On 31/03/17 14:07, Wei Chen wrote:
Xen will do exception syndrome check while some types of exception
take place in EL2. The syndrome check code read the ESR_EL2 register
directly, but in some situation this register maybe overridden by
nested exception.
For example, if we re-enable IRQ
Hi Wei,
On 31/03/17 14:07, Wei Chen wrote:
We want to add HCR_EL2 register to Xen context switch. And each copy
of HCR_EL2 in vcpu structure will be initialized with the same set
of trap flags as the HCR_EL2 register. We introduce a helper here to
represent these flags to be reused easily.
Sign
Hi Wei,
On 31/03/17 14:07, Wei Chen wrote:
Different domains may have different HCR_EL2 flags. For example, the
64-bit domain needs HCR_RW flag but the 32-bit does not need it. So
we give each domain a default HCR_EL2 value and save it in the vCPU's
context.
HCR_EL2 register has only one bit ca
On 03/31/2017 07:19 AM, Juergen Gross wrote:
> Error handling in upload_pm_data() is rather questionable: possible
> errno values from called functions are or'ed together resulting in
> strange return values: -EINVAL and -ENOMEM would e.g. result in
> returning -EXDEV.
And it doesn't matter anyway
Hi Wei,
On 31/03/17 14:07, Wei Chen wrote:
When guest triggers async aborts, in most platform, such aborts
will be routed to hypervisor. But we don't want the hypervisor
to handle such aborts, so we have to route such aborts back to
the guest.
This helper is using the HCR_EL2.VSE (HCR.VA for aa
On 03/31/2017 07:19 AM, Juergen Gross wrote:
> The return value of xen_copy_pct_data() is always 0 and never checked.
> xen_copy_psd_data() returns always 0, too, so checking the value is
> kind of pointless.
>
> Make the functions return void.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris
On 31/03/17 16:05, Konrad Rzeszutek Wilk wrote:
> On Thu, Mar 30, 2017 at 07:42:48PM +0200, Gémes Géza wrote:
>>
>>> On Mon, Mar 27, 2017 at 09:28:14PM +0200, Gémes Géza wrote:
Hi,
Currently the xen build system has optional support for building a minios
(+needed libraries and t
On 31/03/17 16:10, Boris Ostrovsky wrote:
> On 03/31/2017 07:19 AM, Juergen Gross wrote:
>> Error handling in upload_pm_data() is rather questionable: possible
>> errno values from called functions are or'ed together resulting in
>> strange return values: -EINVAL and -ENOMEM would e.g. result in
>>
On Thu, Mar 30, 2017 at 12:13:51AM -0400, Joshua Otto wrote:
[...]
> Will do. As a general question for those following the thread, are there any
> application workloads/benchmarks that people would find particularly
> interesting?
>
I think any memory intense workload will do. Others might have
On Mon, Mar 27, 2017 at 05:06:15AM -0400, Joshua Otto wrote:
> Teach send_checkpoint_dirty_pfn_list() to use write_record()'s new fd
> parameter, avoiding the need for a manual writev().
>
> No functional change.
>
> Signed-off-by: Joshua Otto
Acked-by: Wei Liu
___
On Mon, Mar 27, 2017 at 05:06:14AM -0400, Joshua Otto wrote:
> Right now, write_split_record() - which is delegated to by
> write_record() - implicitly writes to ctx->fd. This means it can't be
> used with the restore context's send_back_fd, which is unhandy.
>
> Add an 'fd' parameter to both wri
On Fri, Mar 31, 2017 at 02:53:55PM +0100, Punit Agrawal wrote:
[...]
>
> Correct!
>
> invalidate_icache() flushes the entire instruction cache which ends up
> being called each time flush_page_to_ram() is invoked from
> alloc_heap_pages(). The patch prevents repeated calls to
> invalidate_icache(
On Fri, Mar 31, 2017 at 09:59:09AM -0400, Boris Ostrovsky wrote:
> On 03/31/2017 09:49 AM, Wei Liu wrote:
> > On Fri, Mar 31, 2017 at 09:43:07AM -0400, Boris Ostrovsky wrote:
> >> On 03/31/2017 06:23 AM, Roger Pau Monné wrote:
> >>> On Thu, Mar 30, 2017 at 07:06:15PM -0400, Boris Ostrovsky wrote:
>
Hi Wei,
On 31/03/17 14:07, Wei Chen wrote:
In previous patch, we have umasked the Abort/SError bit for Xen
in most of its running time. So in some use-cases, we have to
check whether the abort is enabled in current context. For example,
while we want to synchronize SErrors, we have to confirm th
On Fri, Mar 31, 2017 at 09:59:09AM -0400, Boris Ostrovsky wrote:
> On 03/31/2017 09:49 AM, Wei Liu wrote:
> > On Fri, Mar 31, 2017 at 09:43:07AM -0400, Boris Ostrovsky wrote:
> >> On 03/31/2017 06:23 AM, Roger Pau Monné wrote:
> >>> On Thu, Mar 30, 2017 at 07:06:15PM -0400, Boris Ostrovsky wrote:
>
Wei Liu writes:
> On Fri, Mar 31, 2017 at 02:53:55PM +0100, Punit Agrawal wrote:
> [...]
>>
>> Correct!
>>
>> invalidate_icache() flushes the entire instruction cache which ends up
>> being called each time flush_page_to_ram() is invoked from
>> alloc_heap_pages(). The patch prevents repeated c
Hi Wei,
On 31/03/17 14:07, Wei Chen wrote:
In previous patches, we have provided the ability to synchronize
SErrors in exception entries. But we haven't synchronized SErrors
while returning to guest and doing context switch.
So we still have two risks:
1. Slipping hypervisor SErrors to guest. F
>>> On 31.03.17 at 15:22, wrote:
> On 17-03-31 06:51:07, Jan Beulich wrote:
>> >>> On 31.03.17 at 14:40, wrote:
>> > On 17-03-31 04:19:49, Jan Beulich wrote:
>> >> >>> On 31.03.17 at 11:12, wrote:
>> >> > On 17-03-31 02:47:25, Jan Beulich wrote:
>> >> >> >>> On 30.03.17 at 14:10, wrote:
>> >> >
On Fri, Mar 31, 2017 at 04:46:27AM -0600, Jan Beulich wrote:
> >>> On 31.03.17 at 10:07, wrote:
> > On Fri, Mar 31, 2017 at 05:05:44AM +, Tian, Kevin wrote:
> >> > From: Jan Beulich [mailto:jbeul...@suse.com]
> >> > Sent: Monday, March 27, 2017 4:00 PM
> >> >
> >> > >>> On 24.03.17 at 17:54,
Hi Wei,
On 31/03/17 14:07, Wei Chen wrote:
If there is a pending SError while we are doing context switch, if the
SError handle option is "FORWARD", We have to guranatee this serror to
NIT: s/guranatee/guarantee/
s/serror/Serror/
be caught by current vCPU, otherwise it will be caught by nex
There are several functions in xen-acpi-processor which either always
return the same value or where the returned value is never checked.
Make the functions return void.
Signed-off-by: Juergen Gross
---
drivers/xen/xen-acpi-processor.c | 51 +++-
1 file chang
>>> On 31.03.17 at 11:56, wrote:
> On 03/31/2017 10:34 AM, Jan Beulich wrote:
> On 31.03.17 at 08:17, wrote:
>>> On 03/30/2017 06:47 PM, Jan Beulich wrote:
> Speaking of emulated MMIO, I've got this when the guest was crashing
> immediately (pre RETRY loop):
>
> MMIO emulatio
On 17-03-31 08:35:14, Jan Beulich wrote:
> >>> On 31.03.17 at 15:22, wrote:
> > On 17-03-31 06:51:07, Jan Beulich wrote:
> >> >>> On 31.03.17 at 14:40, wrote:
> >> > On 17-03-31 04:19:49, Jan Beulich wrote:
> >> >> >>> On 31.03.17 at 11:12, wrote:
> >> >> > On 17-03-31 02:47:25, Jan Beulich wrot
Hi Wei,
On 31/03/17 14:07, Wei Chen wrote:
If there is a pending SError while we're returning from trap. If the
SError handle option is "DIVERSE", we have to prevent slipping this
hypervisor SError to guest. So we have to use the dsb/isb to guarantee
that the pending hypervisor SError would be c
This patch masks .AnyThread bits in IA32_FIXED_CTR_CTRL MSR for all
versions of Intel Arhcitectural Performance Monitoring. Note that
.AnyThread bit (21) is already masked in IA32_PERFEVTSELx MSRs since
hyperthreading is not exposed to guests and Intel SDM discourages the use of
.AnyThread bit in v
Hi Wei,
On 31/03/17 14:07, Wei Chen wrote:
In the later patches of this series, we want to use the alternative
patching framework to avoid checking serror_op in every entries.
So we define a new cpu feature "SKIP_CHECK_PENDING_VSERROR" for
serror_op. When serror_op is not equal to SERROR_DIVERSE
On 30/03/17 20:54, Julien Grall wrote:
On 30/03/2017 19:55, Stefano Stabellini wrote:
On Thu, 30 Mar 2017, Julien Grall wrote:
On 30/03/17 19:37, Stefano Stabellini wrote:
On Thu, 30 Mar 2017, Julien Grall wrote:
Fair enough. Do you think there is any value in adding only one debug
warning,
Roger Pau Monné writes ("Re: [PATCH] xl: Add 'pvh' config option"):
> On Fri, Mar 31, 2017 at 09:59:09AM -0400, Boris Ostrovsky wrote:
> > That would make the toolstack have three guest types while the
> > hypervisor has two.
Is that a problem, conceptually ? It seems to me to be accurate here.
Hi Wei,
On 31/03/17 08:07, Wei Chen wrote:
This patch is based on the implementation of ARM64, it introduces
alternative runtime patching to ARM32. This allows to patch assembly
instruction at runtime to either fix hardware bugs or optimize for
certain hardware features on ARM32 platform.
Xen h
>>> On 29.03.17 at 16:39, wrote:
> This is required in order to have a variable number of vIO APIC pins, instead
> of the current fixed value (48). Note that this patch only expands the fields
> of the hvm_vioapic struct, without actually introducing any new fields or
> functionality.
>
> The rea
>>> On 29.03.17 at 16:47, wrote:
> Introduce a macro to get a pointer to the hvm_irq for a HVM domain. No
> functional change.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists
>>> On 29.03.17 at 16:47, wrote:
> Rename it to NR_HVM_DOMU_IRQS, and get it's value from the size of the DomU
> vIO
> APIC redirection table.
The line wrapping here is slightly puzzling...
> --- a/xen/include/xen/hvm/irq.h
> +++ b/xen/include/xen/hvm/irq.h
> @@ -76,13 +76,13 @@ struct hvm_girq
On 03/31/2017 05:46 PM, Jan Beulich wrote:
On 31.03.17 at 11:56, wrote:
>> On 03/31/2017 10:34 AM, Jan Beulich wrote:
>> On 31.03.17 at 08:17, wrote:
On 03/30/2017 06:47 PM, Jan Beulich wrote:
>> Speaking of emulated MMIO, I've got this when the guest was crashing
>> immedia
>>> On 31.03.17 at 17:01, wrote:
> On 03/31/2017 05:46 PM, Jan Beulich wrote:
> On 31.03.17 at 11:56, wrote:
>>> On 03/31/2017 10:34 AM, Jan Beulich wrote:
>>> On 31.03.17 at 08:17, wrote:
> On 03/30/2017 06:47 PM, Jan Beulich wrote:
>>> Speaking of emulated MMIO, I've got this w
On 03/31/2017 10:33 AM, Ian Jackson wrote:
> Roger Pau Monné writes ("Re: [PATCH] xl: Add 'pvh' config option"):
>> On Fri, Mar 31, 2017 at 09:59:09AM -0400, Boris Ostrovsky wrote:
>>> That would make the toolstack have three guest types while the
>>> hypervisor has two.
> Is that a problem, concep
On 03/31/2017 10:40 AM, Juergen Gross wrote:
> There are several functions in xen-acpi-processor which either always
> return the same value or where the returned value is never checked.
>
> Make the functions return void.
>
> Signed-off-by: Juergen Gross
> ---
> drivers/xen/xen-acpi-processor.c
On Fri, Mar 31, 2017 at 04:40:56PM +0200, Juergen Gross wrote:
> There are several functions in xen-acpi-processor which either always
> return the same value or where the returned value is never checked.
>
> Make the functions return void.
Well, we could actually check it and do some extra error
>>> On 29.03.17 at 16:47, wrote:
> Rearrange the fields of hvm_irq so that gsi_assert_count can be converted into
> a variable size array and add a new field to account the number of GSIs.
>
> Due to this changes the irq member in the hvm_domain struct also needs to
> become a pointer set at runt
On 03/31/2017 10:46 AM, Mohit Gambhir wrote:
> This patch masks .AnyThread bits in IA32_FIXED_CTR_CTRL MSR for all
> versions of Intel Arhcitectural Performance Monitoring. Note that
> .AnyThread bit (21) is already masked in IA32_PERFEVTSELx MSRs since
> hyperthreading is not exposed to guests and
>>> On 29.03.17 at 16:47, wrote:
> Although it's still always set to VIOAPIC_NUM_PINS (48).
>
> Add a new field to the hvm_ioapic struct to contain the number of pins (number
> of IO redirection table entries) and turn the redirection table into a
> variable
> sized array.
>
> Signed-off-by: Ro
On 31/03/17 17:13, Boris Ostrovsky wrote:
> On 03/31/2017 10:40 AM, Juergen Gross wrote:
>> There are several functions in xen-acpi-processor which either always
>> return the same value or where the returned value is never checked.
>>
>> Make the functions return void.
>>
>> Signed-off-by: Juergen
Hi Stefano,
On 30/03/17 00:48, Stefano Stabellini wrote:
On Fri, 3 Mar 2017, Julien Grall wrote:
Hi Stefano,
On 01/03/17 22:15, Stefano Stabellini wrote:
Move the atomic write of rank->vcpu, which sets the new vcpu target, to
vgic_migrate_irq, at the beginning of the lock protected area (prot
On 31/03/17 17:15, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 31, 2017 at 04:40:56PM +0200, Juergen Gross wrote:
>> There are several functions in xen-acpi-processor which either always
>> return the same value or where the returned value is never checked.
>>
>> Make the functions return void.
>
>
Hi Jan and Boris,
I'm Meng Xu from the University of Pennsylvania.
I'm wondering:
How does Xen (vpmu) handle the general performance counter's overflow interrupt?
Could you point me to the function handler, if Xen does handle it?
---What I want to achieve---
I'm looking at the real-time performa
Add name=value parsing options for com1 and com2 to add flexibility
in setting register values for MMIO UART devices.
Maintain backward compatibility with previous positional parameter
specfications.
eg. com1=115200,8n1,0x3f8,4
eg. com1=baud=115200,parity=n,reg_width=4,reg_shift=2,irq=4
eg. com1=
[Sorry, I cc.ed Quan's previous email at Intel. Change to his current email.]
On Fri, Mar 31, 2017 at 11:41 AM, Meng Xu wrote:
> Hi Jan and Boris,
>
> I'm Meng Xu from the University of Pennsylvania.
>
> I'm wondering:
> How does Xen (vpmu) handle the general performance counter's overflow
> int
>>> On 29.03.17 at 16:47, wrote:
> +static unsigned int base_gsi(const struct domain *d,
> + const struct hvm_vioapic *vioapic)
> +{
> +const struct hvm_vioapic *tmp;
> +unsigned int base_gsi = 0, nr_vioapics = d->arch.hvm_domain.nr_vioapics;
> +
> +for ( tm
>>> On 31.03.17 at 17:41, wrote:
> I'm wondering:
> How does Xen (vpmu) handle the general performance counter's overflow
> interrupt?
> Could you point me to the function handler, if Xen does handle it?
Two simple steps take you there: grep for LVTPC to find which vector
is being used (PMU_APIC
>> When I program the general performance counter to trigger an overflow
>> interrupt, I set the following bits for the event selector register
>> and run a task to generate the L3 cache cache miss.
>> FLAG_ENABLE: 0x40UL
>> FLAG_INT:0x10UL
>> FLAG_USR: 0x01UL
>> L3_ALLMISS_EVENT
Hi Stefano,
On 30/03/17 00:47, Stefano Stabellini wrote:
On Fri, 3 Mar 2017, Julien Grall wrote:
Hi Stefano,
On 01/03/17 22:15, Stefano Stabellini wrote:
A potential race condition occurs when vgic_migrate_irq is called a
second time, while GIC_IRQ_GUEST_MIGRATING is already set. In that case
flight 107033 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107033/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12 mig
This run is configured for baseline tests only.
flight 71132 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71132/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-armhf-xsm 3 host-install(3)
flight 107027 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107027/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-buildfail REGR. vs. 107018
build-i386
(dropping some of the lists)
Michael Young writes ("Re: [Xen-devel] Xen Security Advisory 206 - xenstore
denial of service via repeated update"):
> On Wed, 29 Mar 2017, Xen.org security team wrote:
> >Xen Security Advisory XSA-206
> > version 9
> >
This run is configured for baseline tests only.
flight 71133 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71133/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 3 host-install(3)
Hi Boris,
On Fri, Mar 31, 2017 at 12:01 PM, Boris Ostrovsky
wrote:
>
>>> When I program the general performance counter to trigger an overflow
>>> interrupt, I set the following bits for the event selector register
>>> and run a task to generate the L3 cache cache miss.
>>> FLAG_ENABLE: 0x40U
On 03/31/2017 01:32 PM, Meng Xu wrote:
> Hi Boris,
>
> On Fri, Mar 31, 2017 at 12:01 PM, Boris Ostrovsky
> wrote:
When I program the general performance counter to trigger an overflow
interrupt, I set the following bits for the event selector register
and run a task to generate the
flight 107020 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107020/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumprun-i386 12 guest-destroyfail REGR. vs. 106819
test-xtf-amd64-
Ok, no worries
On Fri, 31 Mar 2017, Oleksandr Andrushchenko wrote:
> Hi, Stefano
>
> Unfortunately I had to switch to other tasks,
>
> but I'll get back to this issue asap
>
> Thank you
>
>
> On 03/30/2017 01:36 AM, Stefano Stabellini wrote:
> > On Wed, 29 Mar 2017, Oleksandr Andrushchenko wr
On Fri, 31 Mar 2017, Julien Grall wrote:
> On 30/03/17 20:54, Julien Grall wrote:
> > On 30/03/2017 19:55, Stefano Stabellini wrote:
> > > On Thu, 30 Mar 2017, Julien Grall wrote:
> > > > On 30/03/17 19:37, Stefano Stabellini wrote:
> > > > > On Thu, 30 Mar 2017, Julien Grall wrote:
> > > Fair enou
To be able to easily send commands to the ITS, create the respective
wrapper functions, which take care of the ring buffer.
The first two commands we implement provide methods to map a collection
to a redistributor (aka host core) and to flush the command queue (SYNC).
Start using these commands fo
Parse the DT GIC subnodes to find every ITS MSI controller the hardware
offers. Store that information in a list to both propagate all of them
later to Dom0, but also to be able to iterate over all ITSes.
This introduces an ITS Kconfig option.
Signed-off-by: Andre Przywara
---
xen/arch/arm/Kconf
Hi,
another desperate try to get the ITS Dom0 emulation series ready.
Major changes this time:
- Instead of allocating struct pending_irq's on the fly during LPI injection,
we allocate them upon mapping a device and assign them upon the LPI
mapping into a radix tree, so that we can quickly loo
Instead of directly manipulating the tables in memory, an ITS driver
sends commands via a ring buffer in normal system memory to the ITS h/w
to create or alter the LPI mappings.
Allocate memory for that buffer and tell the ITS about it to be able
to send ITS commands.
Signed-off-by: Andre Przywara
If a guest disables an LPI, we do not forward this to the associated
host LPI to avoid queueing commands to the host ITS command queue.
So it may happen that an LPI fires nevertheless on the host. In this
case we can bail out early, but have to save the pending state on the
virtual side.
Signed-of
Allow a guest to provide the address and size for the memory regions
it has reserved for the GICv3 pending and property tables.
We sanitise the various fields of the respective redistributor
registers and map those pages into Xen's address space to have easy
access.
Signed-off-by: Andre Przywara
Now that the host part of the ITS code is in place, we can enable the
ITS and also LPIs on each redistributor to get the show rolling.
At this point there would be no LPIs mapped, as guests don't know about
the ITS yet.
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic-v3-its.c | 4
xen/a
The number of LPIs on a host can be potentially huge (millions),
although in practise will be mostly reasonable. So prematurely allocating
an array of struct irq_desc's for each LPI is not an option.
However Xen itself does not care about LPIs, as every LPI will be injected
into a guest (Dom0 for n
The ITS uses device IDs to map LPIs to a device. Dom0 will later use
those IDs, which we directly pass on to the host.
For this we have to map each device that Dom0 may request to a host
ITS device with the same identifier.
Allocate the respective memory and enter each device into an rbtree to
late
The MAPC command associates a given collection ID with a given
redistributor, thus mapping collections to VCPUs.
We just store the vcpu_id in the collection table for that.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3-its.c | 46 ++
1 file ch
Each ITS maps a pair of a DeviceID (for instance derived from a PCI
b/d/f triplet) and an EventID (the MSI payload or interrupt ID) to a
pair of LPI number and collection ID, which points to the target CPU.
This mapping is stored in the device and collection tables, which software
has to provide fo
Upon receiving an LPI, we need to find the right VCPU and virtual IRQ
number to get this IRQ injected.
Iterate our two-level LPI table to find this information quickly when
the host takes an LPI. Call the existing injection function to let the
GIC emulation deal with this interrupt.
Signed-off-by:
For the same reason that allocating a struct irq_desc for each
possible LPI is not an option, having a struct pending_irq for each LPI
is also not feasible. We only care about mapped LPIs, so we can get away
with having struct pending_irq's only for them.
Maintain a radix tree per domain where we d
The INT command sets a given LPI identified by a DeviceID/EventID pair
as pending and thus triggers it to be injected.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3-its.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen
The ARM GICv3 provides a new kind of interrupt called LPIs.
The pending bits and the configuration data (priority, enable bits) for
those LPIs are stored in tables in normal memory, which software has to
provide to the hardware.
Allocate the required memory, initialize it and hand it over to each
r
For each hardware ITS create and initialize a virtual ITS for Dom0.
We use the same memory mapped address to keep the doorbell working.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3-its.c | 32
xen/arch/arm/vgic-v3.c | 17
The ITS stores the target (v)CPU and the (virtual) LPI number in tables.
Introduce functions to walk those tables and translate an device ID -
event ID pair into a pair of virtual LPI and vCPU.
We map those tables on demand - which is cheap on arm64. Also we take
care of the locking on the way, sin
The MAPD command maps a device by associating a memory region for
storing ITEs with a certain device ID.
We store the given guest physical address in the device table, and, if
this command comes from Dom0, tell the host ITS driver about this new
mapping, so it can issue the corresponing host MAPD c
This introduces the ITS command handler for the CLEAR command, which
clears the pending state of an LPI.
This removes a not-yet injected, but already queued IRQ from a VCPU.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3-its.c | 31 +--
1 file changed, 29 inse
Dom0 expects all ITSes in the system to be propagated to be able to
use MSIs.
Create Dom0 DT nodes for each hardware ITS, keeping the register frame
address the same, as the doorbell address that the Dom0 drivers program
into the BARs has to match the hardware.
Signed-off-by: Andre Przywara
---
To let a guest know about the availability of virtual LPIs, set the
respective bits in the virtual GIC registers and let a guest control
the LPI enable bit.
Only report the LPI capability if the host has initialized at least
one ITS.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3.c | 74
The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
pair and actually instantiates LPI interrupts.
We connect the already allocated host LPI to this virtual LPI, so that
any triggering IRQ on the host can be quickly forwarded to a guest.
Beside entering the VCPU and the virtual LPI
The INV command instructs the ITS to update the configuration data for
a given LPI by re-reading its entry from the property table.
We don't need to care so much about the priority value, but enabling
or disabling an LPI has some effect: We remove or push virtual LPIs
to their VCPUs, also check the
The INVALL command instructs an ITS to invalidate the configuration
data for all LPIs associated with a given redistributor (read: VCPU).
This is nasty to emulate exactly with our architecture, so we just scan
the pending table and inject _every_ LPI found there that got enabled.
Signed-off-by: An
The MOVI command moves the interrupt affinity from one redistributor
(read: VCPU) to another.
For now migration of "live" LPIs is not yet implemented, but we store
the changed affinity in the host LPI structure and in our virtual ITTE.
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic-v3-its.c
The DISCARD command drops the connection between a DeviceID/EventID
and an LPI/collection pair.
We mark the respective structure entries as not allocated and make
sure that any queued IRQs are removed.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3-its.c | 30
Create a new file to hold the emulation code for the ITS widget.
For now we emulate the memory mapped ITS registers and provide a stub
to introduce the ITS command handling framework (but without actually
emulating any commands at this time).
Signed-off-by: Andre Przywara
---
xen/arch/arm/Makefi
On Fri, 31 Mar 2017, Jan Beulich wrote:
> >>> On 29.03.17 at 16:23, wrote:
> > On 27/03/17 09:40, Wei Chen wrote:
> >> @@ -154,8 +155,12 @@ static int __apply_alternatives_multi_stop(void
> >> *unused)
> >> int ret;
> >> struct alt_region region;
> >> mfn_t xen_mfn = _m
flight 107021 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107021/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 106842
test-armhf-armhf-libvirt
On Fri, 31 Mar 2017, Wei Chen wrote:
> Xen will do exception syndrome check while some types of exception
> take place in EL2. The syndrome check code read the ESR_EL2 register
> directly, but in some situation this register maybe overridden by
> nested exception.
>
> For example, if we re-enable
On Fri, 31 Mar 2017, Wei Chen wrote:
> Different domains may have different HCR_EL2 flags. For example, the
> 64-bit domain needs HCR_RW flag but the 32-bit does not need it. So
> we give each domain a default HCR_EL2 value and save it in the vCPU's
> context.
>
> HCR_EL2 register has only one bit
101 - 200 of 244 matches
Mail list logo
