On 08/05/2019 18:35, George Dunlap wrote:
> On 5/6/19 7:56 AM, Juergen Gross wrote:
>> In order to prepare core- and socket-scheduling use a new struct
>> sched_item instead of struct vcpu for interfaces of the different
>> schedulers.
>>
>> Rename the per-scheduler functions insert_vcpu and
On 08/05/2019 18:24, George Dunlap wrote:
> On 5/6/19 7:56 AM, Juergen Gross wrote:
>> Instead of using the SCHED_OP() macro to call the different scheduler
>> specific functions add inline wrappers for that purpose.
>>
>> Signed-off-by: Juergen Gross
>
> This seems like a great idea. One minor
flight 135818 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135818/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 20 guest-destroyfail REGR. vs. 135687
Tests which did not
flight 135814 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135814/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 130965
flight 135809 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135809/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs. 135539
flight 135813 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135813/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 135478
On Tue, May 07, 2019 at 03:07:27AM -0600, Jan Beulich wrote:
> >>> On 06.05.19 at 16:50, wrote:
> > --- a/xen/drivers/video/vesa.c
> > +++ b/xen/drivers/video/vesa.c
> > @@ -84,6 +84,7 @@ void __init vesa_early_init(void)
> > void __init vesa_init(void)
> > {
> > struct lfb_prop lfbp;
> >
The mask calculation in pdx_init_mask is wrong when the first bank
starts at address 0x0. The reason is that pdx_init_mask will do '0 - 1'
causing an underflow. As a result, the mask becomes 0x
which is the biggest possible mask and ends up causing a significant
memory waste in the
Hi all,
This series is a small collection of PDX fixes. They are technically
independent but discovered together trying to understand the memory
waste caused by the frametable allocation on Xilinx ZynqMP.
Cheers,
Stefano
The following changes since commit
pfn_to_pdx expects an address, not a size, as a parameter. It expects
the end address, and the masks calculations compensate for any holes
between start and end. Pass the end address to pfn_to_pdx. Also remove
from the result pfn_to_pdx(start_address) because we know that we
don't need to cover
pfn_pdx_hole_setup is meant to skip the first MAX_ORDER bits, but
actually it only skips the first MAX_ORDER-1 bits. The issue was
probably introduced by bdb5439c3f ("x86_64: Ensure frame-table
compression leaves MAX_ORDER aligned"), when changing to loop to start
from MAX_ORDER-1 an adjustment by
On Tue, 7 May 2019, Julien Grall wrote:
> Hi,
>
> On 5/7/19 10:35 AM, Jan Beulich wrote:
> > > > > On 07.05.19 at 10:59, wrote:
> > > On 5/7/19 8:40 AM, Jan Beulich wrote:
> > > > > > > On 06.05.19 at 17:26, wrote:
> > > > > On 5/6/19 10:06 AM, Jan Beulich wrote:
> > > > > > > > > On 03.05.19
On Mon, 6 May 2019, Jan Beulich wrote:
> >>> On 03.05.19 at 22:50, wrote:
> > Fix the issue by passing j+1 and i+1 to find_next_zero_bit and
> > find_next_bit. Also add a check for i >= BITS_PER_LONG because
> > find_{,next_}zero_bit() on x86 assume their last argument to be less
> > than their
Le jeudi, avril 25, 2019 9:34 PM, Andrew Cooper a
écrit :
> On 25/04/2019 00:43, Mathieu Tarral wrote:
>
> > On Wednesday 24 April 2019 14:00, Andrew Cooper andrew.coop...@citrix.com
> > wrote:
> >
> > > On 23/04/2019 22:59, Mathieu Tarral wrote:
> > >
> > > > > > The funny thing is that it's
On Wed, 2019-05-08 at 17:35 +0100, George Dunlap wrote:
> On 5/6/19 7:56 AM, Juergen Gross wrote:
> > Rename the per-scheduler functions insert_vcpu and remove_vcpu to
> > insert_item and remove_item to reflect the change of the parameter.
> > In the schedulers rename local functions switched to
On 5/6/19 7:56 AM, Juergen Gross wrote:
> In order to prepare core- and socket-scheduling use a new struct
> sched_item instead of struct vcpu for interfaces of the different
> schedulers.
>
> Rename the per-scheduler functions insert_vcpu and remove_vcpu to
> insert_item and remove_item to
flight 135805 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135805/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail REGR. vs. 133989
Tests which
On 08/05/2019 17:30, Oleksandr wrote:
On 08.05.19 19:19, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 02/05/2019 18:00, Oleksandr Tyshchenko wrote:
Oleksandr Tyshchenko (4):
xen/arm: drivers: scif: Extend driver to handle other interfaces
xen/arm: drivers: scif: Add support
On 08.05.19 19:19, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 02/05/2019 18:00, Oleksandr Tyshchenko wrote:
Oleksandr Tyshchenko (4):
xen/arm: drivers: scif: Extend driver to handle other interfaces
xen/arm: drivers: scif: Add support for SCIFA compatible UARTs
I have merged
On 5/6/19 7:56 AM, Juergen Gross wrote:
> Instead of using the SCHED_OP() macro to call the different scheduler
> specific functions add inline wrappers for that purpose.
>
> Signed-off-by: Juergen Gross
This seems like a great idea. One minor comment...
> +static inline int sched_init(struct
Hi Oleksandr,
On 02/05/2019 18:00, Oleksandr Tyshchenko wrote:
Oleksandr Tyshchenko (4):
xen/arm: drivers: scif: Extend driver to handle other interfaces
xen/arm: drivers: scif: Add support for SCIFA compatible UARTs
I have merged the first two patches in my branch xen-4.13. I will
TLB helpers in the headers tlbflush.h are currently quite confusing to
use the name may lead to think they are dealing with hypervisors TLBs
while they actually deal with guest TLBs.
Rename them to make it clearer that we are dealing with guest TLBs.
Signed-off-by: Julien Grall
Reviewed-by:
The function flush_xen_text_tlb_local() has been misused and will result
to invalidate the instruction cache more than necessary.
For instance, there are no need to invalidate the instruction cache if
we are setting SCTLR_EL2.WXN.
There are effectively only one caller (i.e free_init_memory()
All the TLBs helpers invalidate all the TLB entries are using the same
pattern:
DSB SY
TLBI ...
DSB SY
ISB
This pattern is following pattern recommended by the Arm Arm to ensure
visibility of updates to translation tables (see K11.5.2 in ARM DDI
0487D.b).
We have been a bit too
Hi all,
I spent the last few months looking at Xen boot and memory management to make
it simpler, more efficient and also more compliant in respect of the Arm Arm.
The full rework is quite consequence (already 150 patches and I haven't yet
finished!), so I am planning to send in smaller part
At the moment, TLB helpers are scattered in 2 headers: page.h (for
Xen TLB helpers) and tlbflush.h (for guest TLB helpers).
This patch is gathering all of them in tlbflush. This will help to
uniformize and update the logic of the helpers in follow-up patches.
Signed-off-by: Julien Grall
Now that we dropped flush_xen_text_tlb_local(), we have only one set of
helpers acting on Xen TLBs. There naming are quite confusing because the
TLB instructions used will act on both Data and Instruction TLBs.
Take the opportunity to rework the documentation that can be confusing
to read as they
At the moment, create_xen_entries will only flush the TLBs if the full
range has successfully been updated. This may lead to leave unwanted
entries in the TLBs if we fail to update some entries.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
---
Changes in v2:
- Add
The logic to set SCTLR_EL2.WXN is the same for the boot CPU and
non-boot CPU. So introduce a function to set the bit and clear TLBs.
This new function will help us to document and update the logic in a
single place.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
---
Changes in v2:
Hello Julien,
On 08.05.19 17:31, Julien Grall wrote:
I haven't seen them with nokpti platform so far. I am curious to know what is
your configuration here.
XEN 4.12 with our patches. Thin Dom0 is a generic armv8 Linux, LK 4.14.75 with
patches from Renesas and us.
DomD is LK 4.14.75 with HW
Hi Andrew,
On 24/04/2019 19:10, Andrew Cooper wrote:
* Use domain_vcpu() rather than opencoding the lookup. Amongst other things,
domain_vcpu() is spectre-v1-safe.
* Unlock the domain immediately after arch_set_info_guest() completes. There
is no need for free_vcpu_guest_context()
On 5/8/19 4:16 PM, Jan Beulich wrote:
On 08.05.19 at 17:08, wrote:
>> On 5/2/19 7:58 AM, Jan Beulich wrote:
>>> --- a/xen/arch/x86/mm/p2m.c
>>> +++ b/xen/arch/x86/mm/p2m.c
>>> @@ -841,15 +841,19 @@ guest_physmap_add_entry(struct domain *d
>>> * any guest-requested type changes
Hi,
On 23/04/2019 09:10, Andrii Anisov wrote:
From: Andrii Anisov
VCPUOP_register_runstate_phys_memory_area is implemented via runstate
area mapping. >
Signed-off-by: Andrii Anisov
---
xen/arch/arm/domain.c| 62 +
xen/arch/x86/domain.c| 105
>> @@ -530,6 +532,55 @@ static int hvmemul_do_mmio_addr(paddr_t mmio_gpa,
>> return hvmemul_do_io_addr(1, mmio_gpa, reps, size, dir, df, ram_gpa);
>> }
>>
>> +static bool hvmemul_send_vm_event(paddr_t gpa, unsigned long gla, gfn_t gfn,
>> + uint32_t
On Wed, 8 May 2019, George Dunlap wrote:
> + Check-in policy
> + ===
> +
> +In order for a patch to be checked in, in general, several conditions
> +must be met:
> +
> +1. In order to get a change to a given file committed, it must have
> + the approval of at least one
>>> On 08.05.19 at 17:08, wrote:
> On 5/2/19 7:58 AM, Jan Beulich wrote:
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -841,15 +841,19 @@ guest_physmap_add_entry(struct domain *d
>> * any guest-requested type changes succeed and remove the IOMMU
>> *
>>> On 08.05.19 at 16:59, wrote:
> On 5/8/19 2:57 PM, Jan Beulich wrote:
> On 07.05.19 at 18:15, wrote:
>>> On 5/2/19 7:58 AM, Jan Beulich wrote:
This is what both callers of guest_physmap_add_page() in memory.c want
(for the !paging_mode_translate() case), and it is also what both
On 5/2/19 7:58 AM, Jan Beulich wrote:
> This is what both callers of guest_physmap_add_page() in memory.c want
> (for the !paging_mode_translate() case), and it is also what both
> callers in gnttab_transfer() need (but have been lacking). The other
> (x86-specific) callers are all HVM-only, and
On 5/8/19 2:57 PM, Jan Beulich wrote:
On 07.05.19 at 18:15, wrote:
>> On 5/2/19 7:58 AM, Jan Beulich wrote:
>>> This is what both callers of guest_physmap_add_page() in memory.c want
>>> (for the !paging_mode_translate() case), and it is also what both
>>> callers in gnttab_transfer() need
On 06/05/2019 12:01, Jan Beulich wrote:
On 06.05.19 at 11:23, wrote:
>> And that was mentioned in the cover letter: cpu hotplug is not yet
>> handled (hence the RFC status of the series).
>>
>> When cpu hotplug is being added it might be appropriate to switch the
>> scheme as you suggested.
On 08/05/2019 14:54, Andrii Anisov wrote:
Does it always fail, or only time to time?
It happens on boot. And those prints are permanent and makes boot time enormous.
I once waited till user prompt (half an hour or so), they calmed on visible
idle, but printed from time to time (maybe on
Hi,
On 23/04/2019 09:10, Andrii Anisov wrote:
From: Andrii Anisov
Following discussion [1] it is introduced and implemented a runstate
registration interface which uses guest's phys address instead of a virtual one.
The new hypercall employes the same data structures as a predecessor, but
>>> On 07.05.19 at 18:15, wrote:
> On 5/2/19 7:58 AM, Jan Beulich wrote:
>> This is what both callers of guest_physmap_add_page() in memory.c want
>> (for the !paging_mode_translate() case), and it is also what both
>> callers in gnttab_transfer() need (but have been lacking). The other
>>
Hello Julien,
On 08.05.19 16:39, Julien Grall wrote:
That's a translation fault level 0 on a stage-1 page-table walk. To confirm you
have kpti disabled, right?
Yes, KPTI is disabled. That's why I'm curious what's wrong with that.
Does it always fail, or only time to time?
It happens on
>>> On 08.05.19 at 13:39, wrote:
> The "nesting" section in the MAINTAINERS file was not initially
> intended to describe the check-in policy for patches, but only how
> nesting worked; but since there was no check-in policy, it has been
> acting as a de-facto policy.
>
> One problem with this
On 5/8/19 12:59 PM, Juergen Gross wrote:
> What about variant 2b:
>
> 1. In order to get a change to a given file committed, it must have
> an Ack or Review from at least one maintainer of that file other than
> the submitter.
>
> 2. In the case the submitter is a maintainer of a modified file
(+xen-devel, juergen, boris)
On 08/05/2019 10:25, Andrii Anisov wrote:
Hello Julien,
On 03.05.19 13:19, Julien Grall wrote:
Could you be a bit more specific about the failure? Do you see "Failed to walk
page-table"?
Sorry for a delayed answer.
Yes, I see еру following, also with your patch
flight 135802 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135802/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-xsm 7 xen-boot fail REGR. vs. 134015
... using the new iommu_group infrastructure.
Because 'sibling' devices are now members of the same iommu_group,
implement the domctl by looking up the relevant iommu_group and walking
the membership list.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
---
xen/drivers/passthrough/iommu.c |
This series is a mixture of tidying and some preparatory work for grouping
PCI devices for the purposes of assignment.
Paul Durrant (5):
iommu: trivial re-organisation to avoid unnecessary test
iommu / x86: move call to scan_pci_devices() out of vendor code
iommu: move iommu_get_ops() into
Currently x86 and ARM differ in their implementation for no good reason.
This patch moves the ARM variant of iommu_get/set_ops() helpers into
common code and modifies them so they deal with the __initconstrel
ops structures used by the x86 IOMMU vendor implementations (adding
__initconstrel to the
An 'if ( !iommu_enabled )' followed by an 'if ( iommu_enabled )' with
only a printk() in between seems a little silly. Move the printk() and
use 'else' instead.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
---
xen/drivers/passthrough/iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2
Some devices may share a single PCIe initiator id, e.g. if they are actually
legacy PCI devices behind a bridge, and hence DMA from such devices will
be subject to the same address translation in the IOMMU. Hence these devices
should be treated as a unit for the purposes of assignment. There are
It's not vendor specific so it shouldn't really be there.
Signed-off-by: Paul Durrant
---
Cc: Suravee Suthikulpanit
Cc: Brian Woods
Cc: Kevin Tian
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
---
xen/drivers/passthrough/amd/pci_amd_iommu.c | 3 ++-
>>> On 08.05.19 at 15:10, wrote:
> All of __{assign,bind,clear}_irq_vector() manipulate struct irq_desc
> fields, and hence ought to be called with the descriptor lock held in
> addition to vector_lock. This is currently the case for only
> set_desc_affinity() (in the common case) and
Its only caller already has the IRQ descriptor in its hands, so there's
no need for the function to re-obtain it. As a result the leading p of
its name is no longer appropriate and hence gets dropped.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@
The subsequent cpumask_intersects() covers the "empty" case quite fine.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -650,9 +650,6 @@ void move_masked_irq(struct irq_desc *de
desc->status &= ~IRQ_MOVE_PENDING;
-if
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
--- a/xen/include/asm-x86/irq.h
+++ b/xen/include/asm-x86/irq.h
@@ -41,8 +41,8 @@ struct arch_irq_desc {
cpumask_var_t cpu_mask;
cpumask_var_t old_cpu_mask;
cpumask_var_t pending_mask;
-unsigned
Since the "Cannot set affinity ..." warning is a one time one, avoid
triggering it already at boot time when parking secondary threads and
the serial console uses a (still unconnected at that time) PCI IRQ.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
--- a/xen/arch/x86/irq.c
+++
If any particular value was to be checked against, it would need to be
IRQ_VECTOR_UNASSIGNED.
Reported-by: Roger Pau Monné
Be more strict though and use valid_irq_vector() instead.
Take the opportunity and also convert local variables to unsigned int.
Signed-off-by: Jan Beulich
---
v2: New.
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-ws16-amd64
testid windows-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu
All of __{assign,bind,clear}_irq_vector() manipulate struct irq_desc
fields, and hence ought to be called with the descriptor lock held in
addition to vector_lock. This is currently the case for only
set_desc_affinity() (in the common case) and destroy_irq(), which also
clarifies what the nesting
Mixed meaning was implied so far by different pieces of code -
disagreement was in particular about whether to expect offline CPUs'
bits to possibly be set. Switch to a mostly consistent meaning
(exception being high priority interrupts, which would perhaps better
be switched to the same model as
desc->arch.cpu_mask reflects the actual set of target CPUs. Don't ever
fiddle with desc->affinity itself, except to store caller requested
values. Note that assign_irq_vector() now takes a NULL incoming CPU mask
to mean "all CPUs" now, rather than just "all currently online CPUs".
This way no
Don't log a stray trailing comma. Shorten a few fields.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -2328,7 +2328,7 @@ static void dump_irqs(unsigned char key)
spin_lock_irqsave(>lock, flags);
-printk("
Dynamically allocated CPU mask objects may be smaller than cpumask_t, so
copying has to be restricted to the actual allocation size. This is
particulary important since the function doesn't bail early when tracing
is not active, so even production builds would be affected by potential
misbehavior
The cleanup IPI may get sent immediately before a CPU gets removed from
the online map. In such a case the IPI would get handled on the CPU
being offlined no earlier than in the interrupts disabled window after
fixup_irqs()' main loop. This is too late, however, because a possible
affinity change
The flag being set may prevent affinity changes, as these often imply
assignment of a new vector. When there's no possible destination left
for the IRQ, the clearing of the flag needs to happen right from
fixup_irqs().
Additionally _assign_irq_vector() needs to avoid setting the flag when
there's
First and foremost this series is trying to deal with CPU offlining
issues, which have become more prominent with the recently
added SMT enable/disable operation in xen-hptool. Later patches
in the series then carry out more or less unrelated changes
(hopefully improvements) noticed while looking
action->ack_type is set once before the timer even gets initialized, and
is never changed later. The timer gets activated only for EOI and UNMASK
types. Hence there's no need to have a respective if() in there. Replace
it by an ASSERT().
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/irq.c
+++
This is a timer handler, so it gets entered with IRQs enabled. Therefore
there's no need to save/restore the IRQ masking flag.
Additionally the final switch()'es ACKTYPE_EOI case re-acquires the lock
just for it to be dropped again right away. Do away with this.
Signed-off-by: Jan Beulich
---
There's no point entering the loop in the function in this case. Instead
there still being something in flight _after_ the loop would be an
actual problem: No timer would be running anymore for issuing the EOI
eventually, and hence this IRQ (and possibly lower priority ones) would
be blocked,
The timer needs to remain active only until all pending IRQ instances
have seen EOIs from their respective domains. Stop it when the in-flight
count has reached zero in desc_guest_eoi(). Note that this is race free
(with __do_IRQ_guest()), as the IRQ descriptor lock is being held at
that point.
>>> On 08.05.19 at 14:06, wrote:
> On Wed, May 08, 2019 at 03:54:45AM -0600, Jan Beulich wrote:
>> >>> On 07.05.19 at 18:43, wrote:
>> > On Tue, May 07, 2019 at 10:12:13AM -0600, Jan Beulich wrote:
>> >> But what's wrong with backporting your change as is?
>> >
>> > If this commit would be
The first patch was sent on its own before; this is a plain resend. The
others have been added to address at least the majority of the
questions raised in
https://lists.xenproject.org/archives/html/xen-devel/2019-04/msg00883.html
1: don't keep EOI timer running without need
2: bail early from
On Wed, May 08, 2019 at 11:17:14AM +, osstest service owner wrote:
> flight 135810 freebsd-master real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/135810/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>
On Wed, May 08, 2019 at 03:54:45AM -0600, Jan Beulich wrote:
> >>> On 07.05.19 at 18:43, wrote:
> > On Tue, May 07, 2019 at 10:12:13AM -0600, Jan Beulich wrote:
> >> >>> On 07.05.19 at 17:38, wrote:
> >> > What do you think about adding something that could be backported?
> >> > Xen is quite
On 08/05/2019 13:39, George Dunlap wrote:
> The "nesting" section in the MAINTAINERS file was not initially
> intended to describe the check-in policy for patches, but only how
> nesting worked; but since there was no check-in policy, it has been
> acting as a de-facto policy.
>
> One problem
The "nesting" section in the MAINTAINERS file was not initially
intended to describe the check-in policy for patches, but only how
nesting worked; but since there was no check-in policy, it has been
acting as a de-facto policy.
One problem with this is that the policy is not complete: It doesn't
On Wed, 2019-05-08 at 12:59 +0300, Andrii Anisov wrote:
> From: Andrii Anisov
>
> ARM's schedule_tail() is called from two places: context_switch() and
> continue_new_vcpu(). Both functions are always called with
> prev!=current. So replace the correspondent check in schedule_tail()
> with
Commit 753ba43d6d16e688 ("xen/sched: fix credit2 smt idle handling")
introduced a regression when switching cpus between cpupools.
When assigning a cpu to a cpupool with credit2 being the default
scheduler csched2_deinit_pdata() is called for the credit2 private data
after the new scheduler's
flight 135897 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135897/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
coverity-amd647 coverity-upload fail REGR. vs. 133615
version
flight 135790 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135790/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail REGR. vs. 133468
Tests which are
flight 135810 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135810/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd-again 5 host-install(5) fail REGR. vs. 135233
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-credit1
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
During a suspend/resume, the xenwatch thread waits for all outstanding
xenstore requests and transactions to complete. This does not work
correctly for transactions started by userspace because it waits for
them to complete after freezing userspace threads which means the
transactions has no way
On 3/7/19 10:34 AM, Jan Beulich wrote:
> While I've not observed this myself, gcc 9 (imo validly) reportedly may
> complain
>
> trace.c: In function '__trace_hypercall':
> trace.c:826:19: error: taking address of packed member of 'struct
> ' may result in an unaligned pointer value
>
>>> On 07.05.19 at 19:33, wrote:
> On 3/8/19 12:14 PM, Jan Beulich wrote:
> On 08.03.19 at 12:58, wrote:
>>> If that’s the case, what about doing something like the attached instead?
>>> It avoids introducing a not-very-obvious BUILD_BUG_ON(), and also I think
>>> makes the algorithm a
On 4/23/19 9:10 AM, Andrii Anisov wrote:
> From: Andrii Anisov
>
> The hypercall employs the same vcpu_register_runstate_memory_area
> structure for the interface, but requires registered area to not
> cross a page boundary.
This needs a lot more information.
I use the following template when
Hello Dario,
Sorry for a delayed answer,
On 26.04.19 18:13, Dario Faggioli wrote:
You're suggesting that's redundant too, aren't you?
Yes, I do.
And have pushed the patch [1].
[1] https://lists.xenproject.org/archives/html/xen-devel/2019-05/msg00597.html
--
Sincerely,
Andrii Anisov.
From: Andrii Anisov
ARM's schedule_tail() is called from two places: context_switch() and
continue_new_vcpu(). Both functions are always called with
prev!=current. So replace the correspondent check in schedule_tail()
with ASSERT() which is the development (debug) build guard.
Signed-off-by:
>>> On 07.05.19 at 18:43, wrote:
> On Tue, May 07, 2019 at 10:12:13AM -0600, Jan Beulich wrote:
>> >>> On 07.05.19 at 17:38, wrote:
>> > What do you think about adding something that could be backported?
>> > Xen is quite insistent on initializing framebuffer, even with
>> > console=com1 or
On 07.05.19 19:02, Julien Grall wrote:
Hi,
Hi, Julien
On 5/2/19 6:00 PM, Oleksandr Tyshchenko wrote:
docs/misc/arm/early-printk.txt | 5 +
xen/arch/arm/Rules.mk | 7 +++
xen/arch/arm/arm32/debug-scif.inc | 17 +++--
3 files changed, 23
93 matches
Mail list logo
