flight 110430 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110430/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail blocked in 109620
test-xtf-amd64-amd64-1 45
flight 110428 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110428/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 5 xen-install fail REGR. vs. 109975
Tests which did
flight 110427 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110427/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 110380
test-armhf-armhf-xl-rtds
On Wed, 14 Jun 2017, Jan Beulich wrote:
> >>> Stefano Stabellini 06/14/17 8:45 PM >>>
> >On Wed, 14 Jun 2017, Jan Beulich wrote:
> >> > +What ACCESS_ONCE does *not* guarantee though is this access is done in a
> >> > +single instruction, so complex or non-native or
This run is configured for baseline tests only.
flight 71564 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71564/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop
On Wed, Jun 14, 2017 at 06:19:20PM +0100, Wei Liu wrote:
> Signed-off-by: Wei Liu
> ---
> tools/xl/xl.h | 1 +
> tools/xl/xl_utils.c | 19 +++
> tools/xl/xl_utils.h | 3 +++
> 3 files changed, 23 insertions(+)
>
> diff --git a/tools/xl/xl.h
flight 110425 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110425/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 110397
test-armhf-armhf-libvirt-raw 12
flight 110423 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110423/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358
Tests which are
On Mon, 12 Jun 2017, Boris Ostrovsky wrote:
> > +
> > static void pvcalls_back_work(struct work_struct *work)
> > {
> > + struct pvcalls_fedata *priv = container_of(work,
> > + struct pvcalls_fedata, register_work);
> > + int notify, notify_all = 0, more = 1;
> > + struct
flight 110455 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110455/
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
On 06/14/2017 03:19 PM, Dushyant Behl wrote:
> The VMEXIT codes listed from EXCEPTION_PF to EXCEPTION_XF had comments
> describe the exitcodes slightly shifted than the expected value.
> The expected exitcode value for page-fault is 78 which should be 0x4E
> and so on till exception XF.
>
>
On Wed, 14 Jun 2017, Juergen Gross wrote:
> On 14/06/17 02:47, Stefano Stabellini wrote:
> > On Tue, 13 Jun 2017, Juergen Gross wrote:
> >> On 02/06/17 21:31, Stefano Stabellini wrote:
> >>> Implement the accept command by calling inet_accept. To avoid blocking
> >>> in the kernel, call
On Wed, Jun 14, 2017 at 2:19 PM, Jan Beulich wrote:
On 13.06.17 at 17:49, wrote:
>> Hi Everyone,
>>
>> I was looking at the SVM setup code in Xen when I noticed that some
>> comments describing the VMEXIT codes look wrong.
>> The processor
The VMEXIT codes listed from EXCEPTION_PF to EXCEPTION_XF had comments
describe the exitcodes slightly shifted than the expected value.
The expected exitcode value for page-fault is 78 which should be 0x4E
and so on till exception XF.
Signed-off-by: Dushyant Behl
On Wed, 14 Jun 2017, Boris Ostrovsky wrote:
> >>> static int backend_disconnect(struct xenbus_device *dev)
> >>> {
> >>> + struct pvcalls_fedata *priv;
> >>> + struct sock_mapping *map, *n;
> >>> + struct sockpass_mapping *mappass;
> >>> + struct radix_tree_iter iter;
> >>> + void **slot;
> >>>
On Wed, Jun 14, 2017 at 07:33:57PM +0100, Andrew Cooper wrote:
> On 14/06/17 15:18, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jun 14, 2017 at 04:24:00AM -0600, Jan Beulich wrote:
> > On 14.06.17 at 12:13, wrote:
> >>> On 14/06/17 11:11, Jan Beulich wrote:
> >>>
On Wed, 14 Jun 2017, Boris Ostrovsky wrote:
> + Stefano for ARM.
>
> On 06/12/2017 10:21 AM, Juergen Gross wrote:
> > Today only a few sysfs nodes under /sys/hypervisor/ are documented
> > for Xen in Documentation/ABI/testing/sysfs-hypervisor-pmu.
> >
> > Add the remaining Xen sysfs nodes under
> Hmm, okay. Are you fine with the attached patch?
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 14/06/17 19:43, Boris Ostrovsky wrote:
>
>> --- a/Documentation/ABI/testing/sysfs-hypervisor-pmu
>> +++ b/Documentation/ABI/testing/sysfs-hypervisor-xen
>> @@ -1,8 +1,19 @@
>> +What: /sys/hypervisor/guest_type
>> +Date: May 2017
>> +KernelVersion: 4.13
>>
>>> Stefano Stabellini 06/14/17 8:45 PM >>>
>On Wed, 14 Jun 2017, Jan Beulich wrote:
>> > +What ACCESS_ONCE does *not* guarantee though is this access is done in a
>> > +single instruction, so complex or non-native or unaligned data types are
>> > +not guaranteed to be
>>> Andrew Cooper 06/14/17 8:34 PM >>>
>Well - I've got a livepatch with such a relocation. It is probably a
>livepatch build tools issue, but the question is whether Xen should ever
>accept such a livepatch or not (irrespective of whether this exact
>relocation is
On Wed, 14 Jun 2017, Jan Beulich wrote:
> > +What ACCESS_ONCE does *not* guarantee though is this access is done in a
> > +single instruction, so complex or non-native or unaligned data types are
> > +not guaranteed to be atomic. If for instance counter would be a 64-bit
> > value
> > +on a
On Wed, 14 Jun 2017, Andre Przywara wrote:
> Hi,
>
> hopefully the final version, with only nits from v11 addressed.
> The same restriction as for the previous versions still apply: the locking
> is considered somewhat insufficient and will be fixed by an upcoming rework.
>
> Patches 01/34 and
flight 110421 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110421/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 110383
test-amd64-i386-xl-qemuu-win7-amd64 16
On 14/06/17 15:18, Konrad Rzeszutek Wilk wrote:
> On Wed, Jun 14, 2017 at 04:24:00AM -0600, Jan Beulich wrote:
> On 14.06.17 at 12:13, wrote:
>>> On 14/06/17 11:11, Jan Beulich wrote:
>>> On 13.06.17 at 22:51, wrote:
> ---
Hi Stefano,
On 06/14/2017 07:15 PM, Stefano Stabellini wrote:
On Wed, 14 Jun 2017, Julien Grall wrote:
In any case, all those macros does not prevent re-ordering at the
processor
level nor read/write atomicity if the variable is misaligned.
My understanding is that the unwritten assumption
On 14/06/17 15:02, Jan Beulich wrote:
On 14.06.17 at 15:44, wrote:
>> On Tue, Jun 13, 2017 at 09:51:35PM +0100, Andrew Cooper wrote:
>>> --- a/xen/arch/arm/arm32/livepatch.c
>>> +++ b/xen/arch/arm/arm32/livepatch.c
>>> @@ -224,21 +224,21 @@ int
On Wed, 14 Jun 2017, Andre Przywara wrote:
> The MAPD command maps a device by associating a memory region for
> storing ITEs with a certain device ID. Since it features a valid bit,
> MAPD also covers the "unmap" functionality, which we also cover here.
> We store the given guest physical address
On Wed, 14 Jun 2017, Julien Grall wrote:
> > > > > In any case, all those macros does not prevent re-ordering at the
> > > > > processor
> > > > > level nor read/write atomicity if the variable is misaligned.
> > > >
> > > > My understanding is that the unwritten assumption in Xen is that
> > > >
On 06/14/2017 05:51 PM, Andre Przywara wrote:
Hi,
Hi Andre,
hopefully the final version, with only nits from v11 addressed.
The same restriction as for the previous versions still apply: the locking
is considered somewhat insufficient and will be fixed by an upcoming rework.
I have
Hi Andre,
On 06/14/2017 05:52 PM, Andre Przywara wrote:
The MAPD command maps a device by associating a memory region for
storing ITEs with a certain device ID. Since it features a valid bit,
MAPD also covers the "unmap" functionality, which we also cover here.
We store the given guest physical
Hi Andre,
On 06/14/2017 05:51 PM, Andre Przywara wrote:
To avoid code duplication in a later patch, introduce a generic function
to remove a virtual IRQ from the VGIC.
Call that function instead of the open-coded version in vgic_migrate_irq().
Signed-off-by: Andre Przywara
Hi Andre,
On 06/14/2017 05:51 PM, Andre Przywara wrote:
So far irq_to_pending() is just a convenience function to lookup
statically allocated arrays. This will change with LPIs, which are
more dynamic, so the memory for their struct pending_irq might go away.
The proper answer to the issue of
Hi Andre,
On 06/14/2017 05:51 PM, Andre Przywara wrote:
The function name gic_remove_from_queues() was a bit of a misnomer,
since it just removes an IRQ from the pending queue, not both queues.
Rename the function to make this more clear, also give it a pointer to
a struct pending_irq directly
Hi Andre,
On 06/14/2017 05:51 PM, Andre Przywara wrote:
When reading the priority value of a virtual interrupt, we were taking
the respective rank lock so far.
However for forwarded interrupts (Dom0 only so far) this may lead to a
deadlock with the following call chain:
- MMIO access to change
On 06/14/2017 01:23 PM, Juergen Gross wrote:
> For support of Xen hypervisor live patching the hypervisor build id is
> needed. Add a node /sys/hypervisor/properties/buildid containing the
> information.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
Hi Stefano,
On 06/14/2017 06:32 PM, Stefano Stabellini wrote:
On Wed, 14 Jun 2017, Julien Grall wrote:
I don't understand your explanation. There are no PV protocols under
xen/, they are implemented in other repositories. I grepped for ACCESS
under xen/include/public, in case you referred to
> --- a/Documentation/ABI/testing/sysfs-hypervisor-pmu
> +++ b/Documentation/ABI/testing/sysfs-hypervisor-xen
> @@ -1,8 +1,19 @@
> +What:/sys/hypervisor/guest_type
> +Date:May 2017
> +KernelVersion: 4.13
> +Contact: xen-de...@lists.xenproject.org
>
On Wed, 14 Jun 2017, Julien Grall wrote:
> On 06/13/2017 11:19 PM, Stefano Stabellini wrote:
> > On Tue, 13 Jun 2017, Julien Grall wrote:
> > > On 12/06/2017 23:34, Stefano Stabellini wrote:
> > > > On Mon, 12 Jun 2017, Julien Grall wrote:
> > > > > Hi Andre,
> > > > >
> > > > > On 09/06/17
On 06/14/2017 01:11 PM, Juergen Gross wrote:
> On 14/06/17 18:58, Boris Ostrovsky wrote:
>> On 06/12/2017 07:53 AM, Juergen Gross wrote:
>>> In a HVM guest the kernel allocates the page for mapping the shared
>>> info structure via extend_brk() today. This will lead to a drop of
>>> performance as
Currently there is no reliable user interface inside a Xen guest to
determine its type (e.g. HVM, PV or PVH). Instead of letting user mode
try to determine this by various rather hacky mechanisms (parsing of
boot messages before they are gone, trying to make use of known subtle
differences in
In order to be able to determine the Xen guest type from within the
guest as a user there is currently no stable interface available.
Add a sysfs node for that purpose as the guest type information is
available for the kernel.
While doing this document all the other Xen related sysfs nodes.
Add
Sync include/xen/interface/version.h with the Xen source.
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
---
include/xen/interface/version.h | 15 +++
1 file changed, 15 insertions(+)
diff --git
For support of Xen hypervisor live patching the hypervisor build id is
needed. Add a node /sys/hypervisor/properties/buildid containing the
information.
Signed-off-by: Juergen Gross
---
V4:
- send correct patch
---
Documentation/ABI/testing/sysfs-hypervisor-xen | 11
Today only a few sysfs nodes under /sys/hypervisor/ are documented
for Xen in Documentation/ABI/testing/sysfs-hypervisor-pmu.
Add the remaining Xen sysfs nodes under /sys/hypervisor/ in a new
file Documentation/ABI/stable/sysfs-hypervisor-xen and add the Xen
specific sysfs docs to the MAINTAINERS
On Wed, 14 Jun 2017, Jan Beulich wrote:
> >>> On 13.06.17 at 19:41, wrote:
> > On Tue, 13 Jun 2017, George Dunlap wrote:
> >> On 13/06/17 08:28, Jan Beulich wrote:
> >> > Furthermore - who would you mean to create these tags? In the
> >> > end I think it should be the
It has always been the case that different xl processes can manipulate the same
domain at the same time. This could be problematic.
This series attempts to provide facility for xl to have a per-domain lock. This
lock should be used whenever xl manipulates an existing domain.
The last patch is an
Signed-off-by: Wei Liu
---
tools/xl/xl.h | 2 ++
tools/xl/xl_cmdtable.c | 5 +
tools/xl/xl_misc.c | 37 +
3 files changed, 44 insertions(+)
diff --git a/tools/xl/xl.h b/tools/xl/xl.h
index 8d667ff444..9cb135baf2 100644
Rename the existing lock to xl_global lock. Refactor the functions to
take the filename and fd so that they can work with any filename and
fd.
No functional change.
Signed-off-by: Wei Liu
---
tools/xl/xl.c | 19 ++-
tools/xl/xl.h | 3
Pure code motion, no functional change.
Signed-off-by: Wei Liu
---
tools/xl/xl_utils.c | 67 +
tools/xl/xl_utils.h | 3 +++
tools/xl/xl_vmcontrol.c | 67 -
3 files
Signed-off-by: Wei Liu
---
tools/xl/xl.h | 1 +
tools/xl/xl_utils.c | 19 +++
tools/xl/xl_utils.h | 3 +++
3 files changed, 23 insertions(+)
diff --git a/tools/xl/xl.h b/tools/xl/xl.h
index 93ec4d7e4c..8d667ff444 100644
--- a/tools/xl/xl.h
+++
On 14/06/17 18:58, Boris Ostrovsky wrote:
> On 06/12/2017 07:53 AM, Juergen Gross wrote:
>> In a HVM guest the kernel allocates the page for mapping the shared
>> info structure via extend_brk() today. This will lead to a drop of
>> performance as the underlying EPT entry will have to be split up
On 06/12/2017 07:53 AM, Juergen Gross wrote:
> In a HVM guest the kernel allocates the page for mapping the shared
> info structure via extend_brk() today. This will lead to a drop of
> performance as the underlying EPT entry will have to be split up into
> 4kB entries as the single shared info
For each hardware ITS create and initialize a virtual ITS for Dom0.
We use the same memory mapped address to keep the doorbell working.
This introduces a function to initialize a virtual ITS.
We maintain a list of virtual ITSes, at the moment for the only
purpose of later being able to free them
Increase the count of MMIO regions needed by one for each ITS Dom0 has
to emulate. We emulate the ITSes 1:1 from the hardware, so the number
is the number of host ITSes.
Signed-off-by: Andre Przywara
Acked-by: Julien Grall
---
In fact, there exists two kind of tasklets: vCPU and
softirq context tasklets. When we want to do vCPU
context tasklet work, we force the idle vCPU (of a
particular pCPU) into execution, and run it from there.
This means there are two possible reasons for choosing
to run the idle vCPU:
1) we want
The MAPD command maps a device by associating a memory region for
storing ITEs with a certain device ID. Since it features a valid bit,
MAPD also covers the "unmap" functionality, which we also cover here.
We store the given guest physical address in the device table, and, if
this command comes
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 our virtual ITTE and the pending_irq.
Signed-off-by: Andre Przywara
Acked-by: Julien
The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
pair and actually instantiates LPI interrupts. MAPI is just a variant
of this comment, where the LPI ID is the same as the event ID.
We connect the already allocated host LPI to this virtual LPI, so that
any triggering LPI on the
The INT command sets a given LPI identified by a DeviceID/EventID pair
as pending and thus triggers it to be injected.
As read_itte() is now eventually used, we add the static keyword.
Signed-off-by: Andre Przywara
Reviewed-by: Julien Grall
---
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 there is at least one ITS emulated
for that guest (which depends on the host having an ITS at the moment).
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.
The MMIO read and write accesses are protected by locks, to avoid any
changing of the property
When LPIs get unmapped by a guest, they might still be in some LR of
some VCPU. Nevertheless we remove the corresponding pending_irq
(possibly freeing it), and detect this case (irq_to_pending() returns
NULL) when the LR gets cleaned up later.
However a *new* LPI may get mapped with the same
Hi,
following up on this:
https://lists.xen.org/archives/html/xen-devel/2017-06/msg01260.html
I did make a patch that moves do_tasklet() up a bit, within idle_loop().
While there, I did a bit more than that... let's see what you guys think. :-D
I've verified that this builds on ARM too, but
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
Acked-by: Julien Grall
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
iterate over all mapped LPIs and filter for those from that particular
VCPU.
Signed-off-by:
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
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
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
Acked-by: Julien Grall
---
Upon receiving an LPI on the host, we need to find the right VCPU and
virtual IRQ number to get this IRQ injected.
Iterate our two-level LPI table to find the domain ID and the virtual
LPI number quickly when the host takes an LPI. We then look up the
right VCPU in the struct pending_irq.
We use
For each device we allocate one struct pending_irq for each virtual
event (MSI).
Provide a helper function which returns the pointer to the appropriate
struct, to be able to find the right struct when given a virtual
deviceID/eventID pair.
Signed-off-by: Andre Przywara
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
Acked-by: Julien Grall
---
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 - and copy the
respective entries before using
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).
This fixes a misnomer in our virtual ITS structure, where the spec is
confusingly using ID_bits in GITS_TYPER to denote the number
For LPIs we later want to dynamically allocate struct pending_irqs.
So beside needing to initialize the struct from there we also need
to clean it up and re-initialize it later on.
Export vgic_init_pending_irq() and extend it to be reusable.
Signed-off-by: Andre Przywara
To get easy access to the VCPU a forwarded LPI interrupt should be
injected to, so far we stored the VCPU ID in the host LPI entry.
However this creates a redundancy, since we keep the target VCPU in
the struct pending_irq already, which we can easily look up given the
domain and the virtual LPI
Hi,
hopefully the final version, with only nits from v11 addressed.
The same restriction as for the previous versions still apply: the locking
is considered somewhat insufficient and will be fixed by an upcoming rework.
Patches 01/34 and 02/34 should be applied for 4.9 still, since they fix
Even though the ITS emulation is not yet in place, the host ITS already
gets initialized and Xen tries to map the host collections.
However for commands to be processed we need to *enable* the ITS, which
will be done in a later patch not yet merged.
So those MAPC commands are not processed and run
vgic_reg64_check_access() checks for a valid access width of a 64-bit
MMIO register, which is useful beyond the current GICv3 emulation only.
Move this function to the vgic-emul.h to be easily reusable.
Signed-off-by: Andre Przywara
Acked-by: Julien Grall
So far irq_to_pending() is just a convenience function to lookup
statically allocated arrays. This will change with LPIs, which are
more dynamic, so the memory for their struct pending_irq might go away.
The proper answer to the issue of preventing stale pointers is
ref-counting, which requires
The function name gic_remove_from_queues() was a bit of a misnomer,
since it just removes an IRQ from the pending queue, not both queues.
Rename the function to make this more clear, also give it a pointer to
a struct pending_irq directly and rely on the VGIC VCPU lock to be
already taken, so this
We enhance struct pending_irq to cache the priority information
for LPIs. Reading the information from there is faster than accessing
the property table from guest memory. Also it use some padding area in
the struct, so does not require more memory.
This introduces the function to retrieve the LPI
The target CPU for an LPI is encoded in the interrupt translation table
entry, so can't be easily derived from just an LPI number (short of
walking *all* tables and find the matching LPI).
To avoid this in case we need to know the VCPU (for the INVALL command,
for instance), put the VCPU ID in the
From: Vijaya Kumar K
This function allows to copy a chunk of data from and to guest physical
memory. It looks up the associated page from the guest's p2m tree
and maps this page temporarily for the time of the access.
This function was originally written by
When reading the priority value of a virtual interrupt, we were taking
the respective rank lock so far.
However for forwarded interrupts (Dom0 only so far) this may lead to a
deadlock with the following call chain:
- MMIO access to change the IRQ affinity, calling the ITARGETSR handler
- this
The host supports a certain number of LPI identifiers, as stored in
the GICD_TYPER register.
Store this number from the hardware register in vgic_v3_hw to allow
injecting the very same number into a guest (Dom0).
DomUs get the legacy number of 10 bits here, since for now it only sees
SPIs, so it
Now that the host part of the ITS code is in place, we can enable the
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
Acked-by: Stefano Stabellini
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
For LPIs the struct pending_irq's are dynamically allocated and the
pointers will be stored in a radix tree. Since an LPI can be "unmapped"
at any time, teach the VGIC how to deal with irq_to_pending() returning
a NULL pointer.
We just do nothing in this case or clean up the LR if the virtual LPI
To avoid code duplication in a later patch, introduce a generic function
to remove a virtual IRQ from the VGIC.
Call that function instead of the open-coded version in vgic_migrate_irq().
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic.c| 9 +
Hi Andre,
On 06/14/2017 04:54 PM, Andre Przywara wrote:
Hi,
On 12/06/17 16:36, Julien Grall wrote:
Hi Andre,
On 09/06/17 18:41, Andre Przywara wrote:
For LPIs we later want to dynamically allocate struct pending_irqs.
So beside needing to initialize the struct from there we also need
to
flight 110417 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110417/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 110374
Hi,
On 12/06/17 16:36, Julien Grall wrote:
> Hi Andre,
>
> On 09/06/17 18:41, Andre Przywara wrote:
>> For LPIs we later want to dynamically allocate struct pending_irqs.
>> So beside needing to initialize the struct from there we also need
>> to clean it up and re-initialize it later on.
>>
flight 110440 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110440/
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
On 06/14/2017 03:37 PM, Volodymyr Babchuk wrote:
Hi Julien,
Hi Volodymyr,
On 14.06.17 17:21, Julien Grall wrote:
PSCI is part of HVC/SMC interface, so it should be handled in
appropriate place: `smccc.c`. This patch just moves PSCI
handler calls from `traps.c` to `smccc.c`.
PSCI is
This run is configured for baseline tests only.
flight 71563 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71563/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-build
I didn't saw your mail. Sorry.
2017-06-14 23:13 GMT+08:00 Zhongze Liu :
> 2017-06-14 22:42 GMT+08:00 Wei Liu :
>> On Wed, Jun 14, 2017 at 09:19:23PM +0800, Zhongze Liu wrote:
>>> Hi Xen developers,
>>>
>>> In
2017-06-14 22:42 GMT+08:00 Wei Liu :
> On Wed, Jun 14, 2017 at 09:19:23PM +0800, Zhongze Liu wrote:
>> Hi Xen developers,
>>
>> In tools/libxc/xc_domain.c:xc_domain_add_to_physmap() the .size field
>> of the xen_add_to_physmap
>> struct can't be controlled by the caller
On Wed, Jun 14, 2017 at 03:42:34PM +0100, Wei Liu wrote:
> On Wed, Jun 14, 2017 at 09:19:23PM +0800, Zhongze Liu wrote:
> > Hi Xen developers,
> >
> > In tools/libxc/xc_domain.c:xc_domain_add_to_physmap() the .size field
> > of the xen_add_to_physmap
> > struct can't be controlled by the caller
On 14/06/17 17:01, Boris Ostrovsky wrote:
> On 06/14/2017 11:00 AM, Juergen Gross wrote:
>> On 14/06/17 16:48, Boris Ostrovsky wrote:
diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
index 84106f9c456c..d641e9970d5d 100644
--- a/drivers/xen/sys-hypervisor.c
1 - 100 of 164 matches
Mail list logo