flight 109791 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109791/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf df642d70e3966c5265e8992d63e39309ab25db7b
baseline version:
ovmf aff463c825a3bd46f2e82
flight 109766 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109766/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-xsm 7 host-ping-check-xen fail REGR. vs. 109758
test-amd64-i386-libv
This run is configured for baseline tests only.
flight 71440 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71440/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 16 guest
On Fri, 2017-05-26 at 13:09 -0700, Volodymyr Babchuk wrote:
> Hello Dario,
>
Hi,
> > Feel free to ask anything. :-)
>
> I'm so unfamiliar, so even don't know what to ask :) But thank you.
> Surely I'll have questions.
>
Sure. As soon as you have one, go ahead with it.
> > The null scheduler is
flight 109764 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109764/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 14 guest-start/debian.repeat fail REGR. vs. 109690
Tests which did n
This run is configured for baseline tests only.
flight 71441 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71441/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-buildfai
Question has been answered. Thanks.
On Thu, May 25, 2017 at 6:35 PM, Bruno Alvisio
wrote:
> Hello all,
>
> Summary
>
> I am using XEN hypervisor to run a HVM with a QEMU backed disk. After I
> start the HVM I use QMP "query-block" command to see the devices of the VM.
> Initially the command ret
Hello Dario,
>> I'm not very familiar with XEN schedulers.
> Feel free to ask anything. :-)
I'm so unfamiliar, so even don't know what to ask :) But thank you.
Surely I'll have questions.
>> Looks like null scheduler
>> is good for hard RT, but isn't fine for a generic consumer system.
>>
> The nu
On 26/05/17 15:40, Carter Yagemann wrote:
> Hi,
>
> A few months ago I extended a prototyping hypervisor called Bareflank to
> include support for Intel Processor Trace (PT) and now I'm trying to
> implement similar functionality in Xen for research. My goal is to
> leverage the existing interfaces
On 26 May 2017 at 12:43, Volodymyr Babchuk wrote:
> Hi Dario,
>
Oops, sorry, George. There was two emails in a row: yours one and
Dario's one. And I overlooked to whom I'm answering.
--
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babc...@gmail.com
__
Hi Dario,
>>> Explanation of what EL0 apps are. What should be their interface with
>>> Xen? Could the interface be the regular hypercall interface? In that
>>> case, what's the benefit compared to stubdoms?
>> I imagined this as separate syscall interface (with finer policy
>> rules). But this ca
Hello Stefano,
>> > The problem with stubdoms is latency and scheduling. It is not
>> > deterministic. We could easily improve the null scheduler to introduce
>> > some sort of non-preemptive scheduling of stubdoms on the same pcpus of
>> > the guest vcpus. It would still require manually pinning
On Fri, 26 May 2017, Juergen Gross wrote:
> On 26/05/17 18:19, Ian Jackson wrote:
> > Juergen Gross writes ("HVM guest performance regression"):
> >> Looking for the reason of a performance regression of HVM guests under
> >> Xen 4.7 against 4.5 I found the reason to be commit
> >> c26f92b8fce3c9df
On 05/19/2017 07:22 PM, Stefano Stabellini wrote:
> Just reply with success to the other end for now. Delay the allocation
> of the actual socket to bind and/or connect.
>
> Signed-off-by: Stefano Stabellini
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> ---
> drivers/xen/pvcalls-back.c
> static void __pvcalls_back_accept(struct work_struct *work)
> {
> + struct sockpass_mapping *mappass = container_of(
> + work, struct sockpass_mapping, register_work);
> + struct sock_mapping *map;
> + struct pvcalls_ioworker *iow;
> + struct pvcalls_back_priv *priv
flight 109759 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109759/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt 5 xen-install fail REGR. vs. 109736
Tests which did not suc
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
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
---
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 number
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
---
xen/arch/arm/vgic-v3-its.c | 15 +++
xen/arch/arm/
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 ag
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 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: A
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
---
xen/arch/arm/vgic-v3-its.c | 66
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 | 27 +++
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 Vijaya as part of an earlier series:
ht
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 fro
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
---
xen/arch/arm/vgic-v3-its.c | 45 +
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 o
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.
As read_itte() is now eventually used, we add the static keyword.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3-i
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 th
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.
For Dom0 we report the same number of interrupts identifiers as t
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 | 21 +
1 file changed, 21 insertions(+)
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm
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
---
xen/arch/arm/vgic-v3.c | 9
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
---
xen/arch/arm/gic-v3-it
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 or
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
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 th
Hi,
yet another rework, addressing comments on v9.
The same restriction as for v9 still apply: the locking is considered
somewhat insufficient and will be fixed by an upcoming rework.
Most of the fixes are smaller changes as requested by the reviewers.
Some preparatory patches have been moved ear
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
Acked-by: Stefano Stabellini
---
xen/arch/arm
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
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
---
xen/arch/arm/vgic.c
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 handl
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
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
n
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 mor
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 do
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
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 +
xen/arch/arm/vgic.c | 1 +
flight 109758 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109758/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeat fail REGR. vs. 109656
Tests which are fa
On 26/05/17 19:04, Dario Faggioli wrote:
> On Fri, 2017-05-26 at 18:14 +0200, Juergen Gross wrote:
>> Looking for the reason of a performance regression of HVM guests
>> under
>> Xen 4.7 against 4.5 I found the reason to be commit
>> c26f92b8fce3c9df17f7ef035b54d97cbe931c7a ("libxl: remove
>> freem
Hi all,
The document below is an RFC version of a design proposal for PCI
Passthrough in Xen on ARM. It aims to describe from an high level perspective
the interaction with the different subsystems and how guest will be able
to discover and access PCI.
Currently on ARM, Xen does not have any know
Hi,
On 26/05/17 11:19, Julien Grall wrote:
> Hi Stefano,
>
> On 25/05/17 22:05, Stefano Stabellini wrote:
>> On Thu, 25 May 2017, Julien Grall wrote:
>>> Hi Stefano,
>>>
>>> On 25/05/2017 19:49, Stefano Stabellini wrote:
On Thu, 25 May 2017, Andre Przywara wrote:
> Hi,
>
> On 23/
On Fri, 2017-05-26 at 18:14 +0200, Juergen Gross wrote:
> Looking for the reason of a performance regression of HVM guests
> under
> Xen 4.7 against 4.5 I found the reason to be commit
> c26f92b8fce3c9df17f7ef035b54d97cbe931c7a ("libxl: remove
> freemem_slack")
> in Xen 4.6.
>
> The problem occurr
This reverts commit c41e0266dd59ab50b7a153157e9bd2a3ad114b53.
When determining Access Rights, Protection Keys only take effect when CR4.PKE
it set, and 4-level paging is active. All other circumstances (notibly, 32bit
PAE paging) skip the Protection Key control mechanism.
Therefore, we do not ne
These bugfixes finally allow my comprehensive XTF test (following several
bugfixes, and the added feature of the 0-level pagetable tests) to complete
successfully on a Skylake Server system, with PKU.
I know this is getting very tight to the line on 4.9, but it would be nice to
get these fixes in.
Despite the claim in the comment (which was based partly on the code already
being like that, and mistaken reasoning because of Xen leaking NX into guest
context), reality differs.
Use of the SMAP feature without NX, or in a 2-level guest, demonstrate an
observable difference between reads and ins
On 26/05/17 18:19, Ian Jackson wrote:
> Juergen Gross writes ("HVM guest performance regression"):
>> Looking for the reason of a performance regression of HVM guests under
>> Xen 4.7 against 4.5 I found the reason to be commit
>> c26f92b8fce3c9df17f7ef035b54d97cbe931c7a ("libxl: remove freemem_sla
Juergen Gross writes ("HVM guest performance regression"):
> Looking for the reason of a performance regression of HVM guests under
> Xen 4.7 against 4.5 I found the reason to be commit
> c26f92b8fce3c9df17f7ef035b54d97cbe931c7a ("libxl: remove freemem_slack")
> in Xen 4.6.
>
> The problem occurre
Looking for the reason of a performance regression of HVM guests under
Xen 4.7 against 4.5 I found the reason to be commit
c26f92b8fce3c9df17f7ef035b54d97cbe931c7a ("libxl: remove freemem_slack")
in Xen 4.6.
The problem occurred when dom0 had to be ballooned down when starting
the guest. The perfo
> static int pvcalls_back_socket(struct xenbus_device *dev,
> struct xen_pvcalls_request *req)
> {
> - return 0;
> + struct pvcalls_back_priv *priv;
> + int ret;
> + struct xen_pvcalls_response *rsp;
> +
> + priv = dev_get_drvdata(&dev->dev);
> +
> + if (req
>>> On 26.05.17 at 16:37, wrote:
> On 05/26/17 17:29, Jan Beulich wrote:
> On 25.05.17 at 11:40, wrote:
>>> I've noticed that, with pages marked NX and vm_event emulation, we can
>>> end up emulating an ud2, for which hvm_emulate_one() returns
>>> X86EMUL_EXCEPTION in hvm_emulate_one_vm_event
On 05/19/2017 07:22 PM, Stefano Stabellini wrote:
> +
> static void pvcalls_back_work(struct work_struct *work)
> {
> + struct pvcalls_back_priv *priv = container_of(work,
> + struct pvcalls_back_priv, register_work);
> + int notify, notify_all = 0, more = 1;
> + struct xe
>>> On 27.04.17 at 16:35, wrote:
> Add handlers for the MSI control, address, data and mask fields in order to
> detect accesses to them and setup the interrupts as requested by the guest.
>
> Note that the pending register is not trapped, and the guest can freely
> read/write to it.
>
> Whether
This run is configured for baseline tests only.
flight 71380 xen-4.7-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71380/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 11 guest-
On 05/19/2017 07:22 PM, Stefano Stabellini wrote:
> Introduce a per-frontend data structure named pvcalls_back_priv. It
> contains pointers to the command ring, its event channel, a list of
> active sockets and a tree of passive sockets (passing sockets need to be
> looked up from the id on listen,
On 26/05/17 15:29, Jan Beulich wrote:
On 25.05.17 at 11:40, wrote:
>> I've noticed that, with pages marked NX and vm_event emulation, we can
>> end up emulating an ud2, for which hvm_emulate_one() returns
>> X86EMUL_EXCEPTION in hvm_emulate_one_vm_event().
> Could you explain what would lead
Hi,
A few months ago I extended a prototyping hypervisor called Bareflank to
include support for Intel Processor Trace (PT) and now I'm trying to
implement similar functionality in Xen for research. My goal is to
leverage the existing interfaces as much as possible to minimize the
number of direct
On 05/26/17 17:29, Jan Beulich wrote:
On 25.05.17 at 11:40, wrote:
>> I've noticed that, with pages marked NX and vm_event emulation, we can
>> end up emulating an ud2, for which hvm_emulate_one() returns
>> X86EMUL_EXCEPTION in hvm_emulate_one_vm_event().
>
> Could you explain what would le
>>> On 25.05.17 at 11:40, wrote:
> I've noticed that, with pages marked NX and vm_event emulation, we can
> end up emulating an ud2, for which hvm_emulate_one() returns
> X86EMUL_EXCEPTION in hvm_emulate_one_vm_event().
Could you explain what would lead to emulation of UD2?
> This, in turn, caus
On 05/26/2017 10:05 AM, Jan Beulich wrote:
On 22.05.17 at 22:45, wrote:
>> Currently, Hot unplug a physical CPU with vpmu enabled may cause
>> system hang due to send a remote call to an offlined pCPU. This
>> patch add a cpu hot unplug notifer to save vpmu context before
>> cpu offline.
>>
>
On 05/26/2017 08:56 AM, Juergen Gross wrote:
> 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, tr
This run is configured for baseline tests only.
flight 71335 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71335/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-520 xtf/test-hvm32-
Olaf Hering writes ("[PATCH] tools/firmware: pass EXTRAVERSION to seabios
build"):
> Having a fixed version string in the seabios binary is cumbersome:
> - it is required to write something to '.version' in the toplevel
>directory of seabios-dir-remove.
> - it is required to pass EXTRAVERSIO
>>> On 22.05.17 at 22:45, wrote:
> Currently, Hot unplug a physical CPU with vpmu enabled may cause
> system hang due to send a remote call to an offlined pCPU. This
> patch add a cpu hot unplug notifer to save vpmu context before
> cpu offline.
>
> Consider one scenario, hot unplug pCPU N with v
Hi Julien,
Thanks for your comments.
>
>
>> +static bool vpl011_reg32_check_access(int size)
>
>
> Please pass hsr_dabt in parameter rather than the size directly. Which BTW
> should have really be unsigned int.
>
ok.
>> +{
>> +return (size == DABT_DOUBLE_WORD)? false : true;
>
>
> This coul
Hello,
This patchset enables masking the reception of write_ctrlreg events depending
on the value of certain bits in that register.
The most representative example is filtering out events when the CR4.PGE
bit is being flipped (global TLB flushes)
Best regards,
Petre
Add support for filtering out the write_ctrlreg monitor events if they
are generated only by changing certains bits.
A new parameter (bitmask) was added to the xc_monitor_write_ctrlreg
function in order to mask the event generation if the changed bits are
set.
Signed-off-by: Petre Pircalabu
---
Add test for write_ctrlreg event handling.
Signed-off-by: Petre Pircalabu
---
tools/tests/xen-access/xen-access.c | 43 -
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/tools/tests/xen-access/xen-access.c
b/tools/tests/xen-access/xen-access.c
i
On 26/05/17 13:56, 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 /sys/hypervisor/ in a new
> file Documentation/ABI/stable/sysfs-hypervisor-xen and ad
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
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 behav
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.
Juer
Having a fixed version string in the seabios binary is cumbersome:
- it is required to write something to '.version' in the toplevel
directory of seabios-dir-remove.
- it is required to pass EXTRAVERSION= to make.
The latter is impossible without this change. For some reason an 'export
EXTRAV
On 26/05/17 01:37, Feng Kan wrote:
On Thu, May 25, 2017 at 12:56 PM, Julien Grall wrote:
(CC toolstack maintainers)
On 25/05/2017 19:58, Feng Kan wrote:
Hi All:
Hello,
This is not specifically against the XEN 4.9. I am using 4.12rc2
kernel on arm64 platform. Started dom0 fine with ACP
flight 109761 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109761/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf aff463c825a3bd46f2e82cc81b6ec959e705f8e9
baseline version:
ovmf 687bde9cac2ce1a45d916
>>> On 26.05.17 at 13:14, wrote:
> populate_physmap() calls alloc_heap_pages() per requested
> extent. alloc_heap_pages() invalidates the entire icache per
> extent. During domain creation, the icache invalidations can be deffered
> until all the extents have been allocated as there is no risk of
When toolstack requests flushing the caches, flush_page_to_ram() is
called for each page of the requested domain. This needs to unnecessary
icache invalidation operations.
Let's take the responsibility of performing icache operations and use
the recently introduced flag to prevent redundant icache
populate_physmap() calls alloc_heap_pages() per requested
extent. alloc_heap_pages() invalidates the entire icache per
extent. During domain creation, the icache invalidations can be deffered
until all the extents have been allocated as there is no risk of
executing stale instructions from the icac
flush_page_to_ram() unconditionally drops the icache. In certain
situations this leads to execessive icache flushes when
flush_page_to_ram() ends up being repeatedly called in a loop.
Introduce a parameter to allow callers of flush_page_to_ram() to take
responsibility of synchronising the icache.
flight 109754 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109754/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt-xsm 4 host-ping-check-native fail in 109744 pass in
109754
test-amd64-i386-libvirt
Hi,
This series improves the number of icache flushes performed when
allocating memory to a domain. This series was previously posted at
[0] and [1].
Changes
v1 -> v2:
* Updated tags
* Added a comment for icache_invalidate() definition for x86 to
explain why it is empty.
RFC -> v1:
* Fixed co
Hi Jan,
On 26/05/17 07:02, Jan Beulich wrote:
On 25.05.17 at 20:00, wrote:
On 05/25/2017 01:46 PM, Julien Grall wrote:
On 25/05/17 18:08, Boris Ostrovsky wrote:
Is this:
https://lists.xenproject.org/archives/html/xen-devel/2017-05/msg02340.html
being deferred to the next RC (if we are hav
Hi Ian,
On 26/05/17 11:44, Ian Jackson wrote:
We don't want to have to set a host property for each ARM host.
Julien writes:
This command line should always work for arm64. If the device-tree
does not provide the property then it is a bug. We want the command
NIT: "does not provide the p
We don't want to have to set a host property for each ARM host.
Julien writes:
This command line should always work for arm64. If the device-tree
does not provide the property then it is a bug. We want the command
line to be as agnostic as possible from the platform.
Reported-by: Julien Gra
flight 109749 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109749/
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
test-amd64-i386-xl-qe
Hi Stefano,
On 25/05/17 22:05, Stefano Stabellini wrote:
On Thu, 25 May 2017, Julien Grall wrote:
Hi Stefano,
On 25/05/2017 19:49, Stefano Stabellini wrote:
On Thu, 25 May 2017, Andre Przywara wrote:
Hi,
On 23/05/17 18:47, Stefano Stabellini wrote:
On Tue, 23 May 2017, Julien Grall wrote:
On 24/05/17 01:48, Bart Van Assche wrote:
> Target drivers must guarantee that struct se_cmd and struct se_tmr_req
> exist as long as target_tmr_work() is in progress. Since the last
> access by the LIO core is a call to .check_stop_free() and since the
> Xen scsiback .check_stop_free() drops a ref
On 24/05/17 01:48, Bart Van Assche wrote:
> This patch simplifies the implementation of the scsiback driver
> but does not change its behavior.
>
> Signed-off-by: Bart Van Assche
> Cc: Juergen Gross
> Cc: Christoph Hellwig
> Cc: Hannes Reinecke
> Cc: David Disseldorp
> Cc: xen-de...@lists.xen
On 26/05/17 10:10, Andre Przywara wrote:
Hi,
On 22/05/17 18:19, Julien Grall wrote:
On 22/05/17 17:50, Andre Przywara wrote:
Hi,
Hi Andre,
On 17/05/17 16:35, Julien Grall wrote:
+}
+spin_unlock(&d->arch.vgic.its_devices_lock);
+
+return pirq;
+}
+
+struct pending_irq *gicv
1 - 100 of 109 matches
Mail list logo
