This prepares support of larger scheduling granularities, e.g. core
scheduling.
Signed-off-by: Juergen Gross
---
xen/common/sched_arinc653.c | 6 ++---
xen/common/sched_credit.c | 14 +--
xen/common/sched_credit2.c| 24 +--
xen/common/sched_null.c | 8 ++
flight 135674 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135674/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow216 guest-saverestore.2 fail REGR. vs. 133989
Tests which di
On 06/05/2019 08:55, Juergen Gross wrote:
> Add support for core- and socket-scheduling in the Xen hypervisor.
The series is available under:
github.com/jgross1/xen.git sched-rfc-v2
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 03.05.19 20:09, Julien Grall wrote:
I will reword to "Thankfully Xen provides an handy macro that will make the code
more readable".
Good.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xen
>>> On 03.05.19 at 16:10, wrote:
On 03.05.19 at 11:19, wrote:
>> On Mon, Apr 29, 2019 at 09:40:14AM -0600, Jan Beulich wrote:
>>> --- unstable.orig/xen/arch/x86/irq.c
>>> +++ unstable/xen/arch/x86/irq.c
>>> @@ -242,6 +242,20 @@ void destroy_irq(unsigned int irq)
>>> xfree(action
branch xen-4.11-testing
xenbranch xen-4.11-testing
job test-arm64-arm64-xl-credit2
testid xen-boot
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/x
>>> On 03.05.19 at 17:21, wrote:
> On Mon, Apr 29, 2019 at 05:23:20AM -0600, Jan Beulich wrote:
>> 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 disa
On 05/05/2019 15:27, Marek Marczykowski-Górecki wrote:
> Hi,
>
> I have a machine that allocate vesa LFB above 4GB, as reported by UEFI
> GOP. At 0x40 to be specific.
> vga_console_info.u.vesa_lfb.lfb_base is a 32bit field, so it gets
> truncated, leading to all kind of memory corruptions
>>> On 03.05.19 at 17:43, wrote:
> On Mon, Apr 29, 2019 at 05:23:49AM -0600, Jan Beulich wrote:
>> Don't log a stray trailing comma. Shorten a few fields.
>>
>> Signed-off-by: Jan Beulich
>
> Reviewed-by: Roger Pau Monné
Thanks.
>> -for ( i = 0; i < action->nr_guests; i++ )
>> +
On 03/05/2019 17:04, Roger Pau Monne wrote:
> There's no reason to request physically contiguous memory for those
> allocations.
>
> Reported-by: Ian Jackson
> Signed-off-by: Roger Pau Monné
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing
>>> On 03.05.19 at 18:21, wrote:
> On Mon, Apr 29, 2019 at 05:24:39AM -0600, Jan Beulich wrote:
>> 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.
>>
>> This renders both set_native_irq_info()
Hello Julien,
On 03.05.19 20:19, Julien Grall wrote:
TLDR; because xen page-tables are not that often modified after boot. Yet it is
still possible to race.
At the moment, create_xen_entries() can only modify the VA range 0 - 2GB. In
that range, we can modify at runtime the VMAP area. One pot
On 22.04.19 19:49, Julien Grall wrote:
The function create_xen_entries may be concurrently called. So we need
to protect with a spinlock to avoid corruption the page-tables.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
--
Sincerely,
Andrii Anisov.
__
On 03.05.19 20:06, Julien Grall wrote:
In C, uninitialized global variable will be zero by default. It is a bit of
waste to allocate space in the binary for them. So the compiler will commonly
put them in a section BSS that are going to be zeroed when at launch.
On Arm32, this is always done
>>> On 06.05.19 at 08:56, wrote:
> @@ -207,6 +250,141 @@ static inline void sched_free_domdata(const struct
> scheduler *s,
> ASSERT(!data);
> }
>
> +static inline void *sched_alloc_pdata(const struct scheduler *s, int cpu)
> +{
> +if ( s->alloc_pdata )
> +return s->alloc_
On 06/05/2019 10:27, Jan Beulich wrote:
On 06.05.19 at 08:56, wrote:
>> @@ -207,6 +250,141 @@ static inline void sched_free_domdata(const struct
>> scheduler *s,
>> ASSERT(!data);
>> }
>>
>> +static inline void *sched_alloc_pdata(const struct scheduler *s, int cpu)
>> +{
>> +
>>> On 06.05.19 at 08:56, wrote:
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -808,21 +808,24 @@ static void vcpu_migrate_finish(struct vcpu *v)
> }
>
> /*
> - * Force a VCPU through a deschedule/reschedule path.
> - * For example, using this when setting the periodic timer
On 06/05/2019 10:37, Jan Beulich wrote:
On 06.05.19 at 08:56, wrote:
>> --- a/xen/common/schedule.c
>> +++ b/xen/common/schedule.c
>> @@ -808,21 +808,24 @@ static void vcpu_migrate_finish(struct vcpu *v)
>> }
>>
>> /*
>> - * Force a VCPU through a deschedule/reschedule path.
>> - * For ex
>>> On 06.05.19 at 08:56, wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1701,6 +1701,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> printk(XENLOG_INFO "Parked %u CPUs\n", num_parked);
> smp_cpus_done();
>
> +scheduler_smp_init();
> +
>
>>> On 06.05.19 at 10:34, wrote:
> On 06/05/2019 10:27, Jan Beulich wrote:
> On 06.05.19 at 08:56, wrote:
>>> @@ -207,6 +250,141 @@ static inline void sched_free_domdata(const struct
>>> scheduler *s,
>>> ASSERT(!data);
>>> }
>>>
>>> +static inline void *sched_alloc_pdata(const s
>>> On 03.05.19 at 22:50, wrote:
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -481,10 +481,15 @@ static paddr_t __init next_module(paddr_t s, paddr_t
> *end)
> static void __init init_pdx(void)
> {
> paddr_t bank_start, bank_size, bank_end;
> -
> -u64 mask = pdx_init_
>>> 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 middle one.
I had pointed out x86 since I knew it
On 06/05/2019 10:57, Jan Beulich wrote:
On 06.05.19 at 08:56, wrote:
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -1701,6 +1701,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>> printk(XENLOG_INFO "Parked %u CPUs\n", num_parked);
>> smp_cpus_done
Paul,
>>> On 05.05.19 at 12:54, wrote:
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-i386-xl-qemut-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:/
>>> On 06.05.19 at 06:44, wrote:
> On Thu, May 02, 2019 at 10:20:09AM +0200, Roger Pau Monné wrote:
>>Can you see about avoiding the XEN_DOMCTL_bind_pt_irq call in QEMU if
>>the interrupt is going to be routed over an event channel?
>
> Yes. It is doable. But it needs changes in both qemu and Xen
>>> On 06.05.19 at 10:04, wrote:
> On 05/05/2019 15:27, Marek Marczykowski-Górecki wrote:
>> Hi,
>>
>> I have a machine that allocate vesa LFB above 4GB, as reported by UEFI
>> GOP. At 0x40 to be specific.
>> vga_console_info.u.vesa_lfb.lfb_base is a 32bit field, so it gets
>> truncated,
>>> On 06.05.19 at 11:23, wrote:
> On 06/05/2019 10:57, Jan Beulich wrote:
> On 06.05.19 at 08:56, wrote:
>>> void scheduler_percpu_init(unsigned int cpu)
>>> {
>>> struct scheduler *sched = per_cpu(scheduler, cpu);
>>> struct sched_resource *sd = per_cpu(sched_res, cpu);
>>> +
On 06/05/2019 12:01, Jan Beulich wrote:
On 06.05.19 at 11:23, wrote:
>> On 06/05/2019 10:57, Jan Beulich wrote:
>> On 06.05.19 at 08:56, wrote:
void scheduler_percpu_init(unsigned int cpu)
{
struct scheduler *sched = per_cpu(scheduler, cpu);
struct sched_r
On Mon, May 06, 2019 at 12:44:41PM +0800, Chao Gao wrote:
> On Thu, May 02, 2019 at 10:20:09AM +0200, Roger Pau Monné wrote:
> >On Wed, May 01, 2019 at 12:41:13AM +0800, Chao Gao wrote:
> >> On Tue, Apr 30, 2019 at 11:30:33AM +0200, Roger Pau Monné wrote:
> >> >On Tue, Apr 30, 2019 at 05:01:21PM +0
On Mon, May 06, 2019 at 03:57:06AM -0600, Jan Beulich wrote:
> >>> On 06.05.19 at 10:04, wrote:
> > On 05/05/2019 15:27, Marek Marczykowski-Górecki wrote:
> >> Hi,
> >>
> >> I have a machine that allocate vesa LFB above 4GB, as reported by UEFI
> >> GOP. At 0x40 to be specific.
> >> vga_c
>>> On 06.05.19 at 12:29, wrote:
> BTW another problem I have on this machine is the framebuffer size. It's
> 3840 x 2160, which is larger than max resolution hardcoded in
> drivers/video/lfb.c (1920 x 1200). efi_find_gop_mode() chooses the
> largest one, ignoring this limit. On one hand, it shoul
On Mon, Apr 29, 2019 at 05:25:03AM -0600, Jan Beulich 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() and destro
>>> On 06.05.19 at 12:20, wrote:
> On 06/05/2019 12:01, Jan Beulich wrote:
> On 06.05.19 at 11:23, wrote:
>>> On 06/05/2019 10:57, Jan Beulich wrote:
. Yet then I'm a little puzzled by its use here in the first place.
Generally I think for_each_cpu() uses in __init functions are
>>>
On 06/05/2019 13:58, Jan Beulich wrote:
On 06.05.19 at 12:20, wrote:
>> On 06/05/2019 12:01, Jan Beulich wrote:
>> On 06.05.19 at 11:23, wrote:
On 06/05/2019 10:57, Jan Beulich wrote:
> . Yet then I'm a little puzzled by its use here in the first place.
> Generally I think f
On 24.04.19 19:59, Julien Grall wrote:
With the newly introduced flags, it is now possible to know how the page
will be updated through the flags.
All the use of xenmap_operation are not replaced with the flags. At the
I suppose it should be "are noW replaced with the flags".
same time, va
On 24.04.19 19:59, Julien Grall wrote:
Currently, the MFN will be incremented even if it is invalid. This will
result to have a valid MFN after the first iteration.
While this is not a major problem today, this will be in the future if
the code expect an invalid MFN at every iteration.
Such b
On 24.04.19 19:59, Julien Grall wrote:
{set, clear}_fixmap() are currently open-coding update to the Xen
page-tables. This can be avoided by using the generic helpers
map_pages_to_xen() and destroy_xen_mappings().
Both function are not meant to fail for fixmap, hence the BUG_ON()
checking the
On 24.04.19 19:59, Julien Grall wrote:
The enum xenmap_operation is not used anymore. So remove it.
Signed-off-by: Julien Grall
---
Reviewed-by: Andrii Anisov
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.or
On 24.04.19 19:59, Julien Grall wrote:
Currently, the virtual address of the 3rd level page-tables is obtained
using mfn_to_virt().
On Arm32, mfn_to_virt can only work on xenheap page. While in practice
all the page-tables updated will reside in xenheap, in practive the
page-tables covering Xe
On 24.04.19 19:59, Julien Grall wrote:
Currently, xen_pt_update_entry() is only able to update the region covered
by xen_second (i.e 0 to 0x7fff).
Because of the restriction we end to have multiple functions in mm.c
modifying the page-tables differently.
Furthermore, we never walked the p
On 24.04.19 19:59, Julien Grall wrote:
There are few places requiring to generate offsets from an address.
Rather than open-coding everywhere, we can introduce a macro to do the
job for us.
Signed-off-by: Julien Grall
---
xen/arch/arm/p2m.c | 23 +++
xen/include
Give the administrator further control on when to scrub domheap pages by adding
an option to always scrub. This is a safety feature that, when enabled,
prevents a (buggy) domain from leaking secrets if it accidentally frees a page
without proper scrubbing.
Signed-off-by: Eslam Elnikety
---
docs/
Hello Julien,
On 24.04.19 19:59, Julien Grall wrote:
The code handling Xen PT update has quite a few restrictions on what it
can do. This is not a bad thing as it keeps the code simple.
There are already a few checks scattered in current page table handling.
However they are not sufficient as t
On 24.04.19 19:59, Julien Grall wrote:
At the moment, the flags are not enough to describe what kind of update
will done on the VA range. They need to be used in conjunction with the
enum xenmap_operation.
It would be more convenient to have all the information for the update
in a single place
On 24.04.19 19:59, Julien Grall wrote:
set_pte_flags_on_range() is yet another function that will open-code
update to a specific range in the Xen page-tables. It can be completely
dropped by using either modify_xen_mappings() or destroy_xen_mappings().
Signed-off-by: Julien Grall
---
Review
On 24.04.19 19:59, Julien Grall wrote:
create_xen_entries() is doing more than creating entries. It can also
modify and remove entries.
Rename the function to make clear what the function is actually doing.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
--
Sincerely,
Andrii Aniso
On 24.04.19 19:59, Julien Grall wrote:
In preparation of rework of the Xen PT, the logic to update an entry
in moved out in a separate function.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
--
Sincerely,
Andrii Anisov.
___
Xen-devel
>>> On 06.05.19 at 13:48, wrote:
> On Mon, Apr 29, 2019 at 05:25:03AM -0600, Jan Beulich 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 fo
flight 135675 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135675/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-migrupgrade 24 leak-check/check/src_host fail REGR. vs. 135478
test-amd64-am
>>> On 06.05.19 at 14:23, wrote:
> On 06/05/2019 13:58, Jan Beulich wrote:
> On 06.05.19 at 12:20, wrote:
>>> On 06/05/2019 12:01, Jan Beulich wrote:
>>> On 06.05.19 at 11:23, wrote:
> On 06/05/2019 10:57, Jan Beulich wrote:
>> . Yet then I'm a little puzzled by its use here in t
On 06/05/2019 15:14, Jan Beulich wrote:
On 06.05.19 at 14:23, wrote:
>> On 06/05/2019 13:58, Jan Beulich wrote:
>> On 06.05.19 at 12:20, wrote:
On 06/05/2019 12:01, Jan Beulich wrote:
On 06.05.19 at 11:23, wrote:
>> On 06/05/2019 10:57, Jan Beulich wrote:
>>> . Yet
On Mon, Apr 29, 2019 at 05:26:10AM -0600, Jan Beulich wrote:
> The subsequent cpumask_intersects() covers the "empty" case quite fine.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
___
Xen-devel mailing list
Xen-devel@lists.xenproject.o
Hi all,
Please propose topics by either editing the running agenda document at
https://docs.google.com/document/d/1ktN-5u8uScEvhf9N8Um5o6poF12lVEnnySHJw_7Jk8k/edit#
or by replying to the mail. Ideally by Wednesday!
Best Regards
Lars
== Dial-in Information ==
## Meeting time
15:00 - 16:00 UT
On Mon, Apr 29, 2019 at 05:26:41AM -0600, Jan Beulich wrote:
> 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 B
>>> On 06.05.19 at 15:52, wrote:
> On Mon, Apr 29, 2019 at 05:26:41AM -0600, Jan Beulich wrote:
>> --- a/xen/arch/x86/irq.c
>> +++ b/xen/arch/x86/irq.c
>> @@ -2412,8 +2412,20 @@ void fixup_irqs(const cpumask_t *mask, b
>> vector = irq_to_vector(irq);
>> if ( vector >= FIRST_HIPRI
On Mon, May 06, 2019 at 01:15:59AM -0600, Jan Beulich wrote:
> >>> On 03.05.19 at 16:10, wrote:
> On 03.05.19 at 11:19, wrote:
> >> On Mon, Apr 29, 2019 at 09:40:14AM -0600, Jan Beulich wrote:
> >>> --- unstable.orig/xen/arch/x86/irq.c
> >>> +++ unstable/xen/arch/x86/irq.c
> >>> @@ -24
flight 135677 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135677/
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
build-i386-prev
On Mon, May 06, 2019 at 08:25:51AM -0600, Jan Beulich wrote:
> >>> On 06.05.19 at 15:52, wrote:
> > On Mon, Apr 29, 2019 at 05:26:41AM -0600, Jan Beulich wrote:
> >> --- a/xen/arch/x86/irq.c
> >> +++ b/xen/arch/x86/irq.c
> >> @@ -2412,8 +2412,20 @@ void fixup_irqs(const cpumask_t *mask, b
> >>
>>> On 06.05.19 at 16:28, wrote:
> On Mon, May 06, 2019 at 01:15:59AM -0600, Jan Beulich wrote:
>> >>> On 03.05.19 at 16:10, wrote:
>> On 03.05.19 at 11:19, wrote:
>> >> On Mon, Apr 29, 2019 at 09:40:14AM -0600, Jan Beulich wrote:
>> >>> --- unstable.orig/xen/arch/x86/irq.c
>> >>> +++
MAX_BPP, MAX_FONT_W, MAX_FONT_H are not used in the code at all.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/video/lfb.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/xen/drivers/video/lfb.c b/xen/drivers/video/lfb.c
index d0c8c49..0475a68 100644
--- a/xen/drivers/video/lfb
The limit 1900x1200 do not match real world devices (1900 looks like a
typo, should be 1920). But in practice the limits are arbitrary and do
not serve any real purpose. As discussed in "Increase framebuffer size
to todays standards" thread, drop them completely.
This fixes graphic console on devi
When bitmap_fill(..., 0) is called, do not try to write anything. Before
this patch, it tried to write almost LONG_MAX, surely overwriting
something.
Signed-off-by: Marek Marczykowski-Górecki
---
Found while debugging framebuffer located above 4GB. In that case 32bit
variable for it overflows and
On some machines (for example Thinkpad P52), UEFI GOP reports
framebuffer located above 4GB (0x40 on that machine). This
address does not fit in {xen,dom0}_vga_console_info.u.vesa_lfb.lfb_base
field, which is 32bit. The overflow here cause all kind of memory
corruption when anything tries t
A bunch of fixes for booting Xen on Thinkpad P52, through grub2-efi +
multiboot2. Most of them can be applied independently.
---
cc: Andrew Cooper
cc: George Dunlap
cc: Ian Jackson
cc: Jan Beulich
cc: Julien Grall
cc: Konrad Rzeszutek Wilk
cc: Stefano Stabellini
cc: Tim Deegan
cc: Wei Liu
vlfb_info is an alias for vga_console_info.u.vesa_lfb, so this change is
purely cosmetic. But using the same name helps reading the code.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/video/vesa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/drivers/video/v
On Mon, May 06, 2019 at 07:51:17AM -0600, Lars Kurth wrote:
> [CAUTION: External Email]
>
> Hi all,
>
> Please propose topics by either editing the running agenda document at
> https://docs.google.com/document/d/1ktN-5u8uScEvhf9N8Um5o6poF12lVEnnySHJw_7Jk8k/edit#
> or by replying to the mail. Id
Am Mon, 6 May 2019 16:50:19 +0200
schrieb Marek Marczykowski-Górecki :
> The limit 1900x1200 do not match real world devices (1900 looks like a
> typo, should be 1920). But in practice the limits are arbitrary and do
> not serve any real purpose. As discussed in "Increase framebuffer size
> to to
On 06/05/2019 16:50, Marek Marczykowski-Górecki wrote:
> On some machines (for example Thinkpad P52), UEFI GOP reports
> framebuffer located above 4GB (0x40 on that machine). This
> address does not fit in {xen,dom0}_vga_console_info.u.vesa_lfb.lfb_base
> field, which is 32bit. The overflow
On 06/05/2019 15:50, Marek Marczykowski-Górecki wrote:
> When bitmap_fill(..., 0) is called, do not try to write anything. Before
> this patch, it tried to write almost LONG_MAX, surely overwriting
> something.
>
> Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Andrew Cooper
It looks li
On 06/05/2019 15:50, Marek Marczykowski-Górecki wrote:
> MAX_BPP, MAX_FONT_W, MAX_FONT_H are not used in the code at all.
>
> Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
h
> On 6 May 2019, at 09:11, Woods, Brian wrote:
>
> On Mon, May 06, 2019 at 07:51:17AM -0600, Lars Kurth wrote:
>> [CAUTION: External Email]
>>
>> Hi all,
>>
>> Please propose topics by either editing the running agenda document at
>> https://docs.google.com/document/d/1ktN-5u8uScEvhf9N8Um5o6
On Mon, 2019-05-06 at 08:56 +0200, 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
> @@ -207,6 +250,141 @@ static inline void sched_free_domdata(const
> struct
Hi Jan,
On 5/6/19 10:06 AM, Jan Beulich wrote:
On 03.05.19 at 22:50, wrote:
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -481,10 +481,15 @@ static paddr_t __init next_module(paddr_t s, paddr_t *end)
static void __init init_pdx(void)
{
paddr_t bank_start, bank_size, bank_e
On 06/05/2019 15:50, Marek Marczykowski-Górecki wrote:
> diff --git a/xen/drivers/video/vesa.c b/xen/drivers/video/vesa.c
> index c92497e..f22cf7f 100644
> --- 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(
On Mon, May 06, 2019 at 05:15:19PM +0200, Juergen Gross wrote:
> On 06/05/2019 16:50, Marek Marczykowski-Górecki wrote:
> > diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> > index ccdffc0..b0f0f7e 100644
> > --- a/xen/include/public/xen.h
> > +++ b/xen/include/public/xen.h
> > @@
On 06/05/2019 15:50, Marek Marczykowski-Górecki wrote:
> vlfb_info is an alias for vga_console_info.u.vesa_lfb, so this change is
> purely cosmetic. But using the same name helps reading the code.
>
> Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Andrew Cooper
On 06/05/2019 15:50, Marek Marczykowski-Górecki wrote:
> The limit 1900x1200 do not match real world devices (1900 looks like a
> typo, should be 1920). But in practice the limits are arbitrary and do
> not serve any real purpose. As discussed in "Increase framebuffer size
> to todays standards" th
On 03/05/2019 20:43, Eslam Elnikety wrote:
> When unpausing a capped domain, the scheduler currently clears the
> CSCHED_FLAG_VCPU_PARKED flag before vcpu_wake(). This, in turn, causes the
> vcpu_wake to set CSCHED_PRI_TS_BOOST, resulting in an unfair credit boost. The
> comment around the changed
On 06/05/2019 15:50, Marek Marczykowski-Górecki wrote:
> A bunch of fixes for booting Xen on Thinkpad P52, through grub2-efi +
> multiboot2. Most of them can be applied independently.
Patches 1-3,5 are all trivially correct, and I've pulled them into x86-next.
~Andrew
___
This is also useful information when looking at boot logs.
To do this, reuse get_model_name() which requires c->extended_cpuid_level to
be calculated. early_cpu_init() already opencodes the calculation, so set
c->extended_cpuid_level directly.
While playing in this area, clean up get_model_name(
Hi,
I would like to submit a strange bug that i'm facing while using DRAKVUF to
monitor applications from the hypervisor.
I wanted to evaluate DRAKVUF's robustness, so I built a test suite, and began
by executing reg.exe via shellexec injection, having the execution tracked by
the procmon plugin
On 5/6/19 9:20 AM, Andrii Anisov wrote:
Hello Julien,
On 03.05.19 20:19, Julien Grall wrote:
TLDR; because xen page-tables are not that often modified after boot.
Yet it is still possible to race.
At the moment, create_xen_entries() can only modify the VA range 0 -
2GB. In that range, we c
Hi,
On 5/6/19 1:48 PM, Andrii Anisov wrote:
+ /* Sanity check when removing a page. */
+ else if ( (flags & (_PAGE_PRESENT|_PAGE_POPULATE)) != 0 )
Shouldn't it be `(flags & (_PAGE_PRESENT|_PAGE_POPULATE)) == 0` ? As I
understand from the patch 04, we do remove a page when we do unset bo
On 06/05/2019 17:18, Mathieu Tarral wrote:
> Hi,
>
> I would like to submit a strange bug that i'm facing while using DRAKVUF to
> monitor applications from the hypervisor.
>
> I wanted to evaluate DRAKVUF's robustness, so I built a test suite, and began
> by executing reg.exe via shellexec injecti
Hi Andrew,
thanks for helping brainstorming on this.
> How exactly does DRAKVUF go about injecting silent breakpoints? It obviously
> has to allocate a new gfn from somewhere to begin with. Do the bifurcated
> frames end up in two different altp2ms, or one in the host p2m and one in an
> alte
flight 135680 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135680/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install fail REGR. vs. 134763
test-amd64-i386-xl
On 06/05/2019 18:41, Tamas K Lengyel wrote:
> Hi Andrew,
> thanks for helping brainstorming on this.
>
>> How exactly does DRAKVUF go about injecting silent breakpoints? It
>> obviously has to allocate a new gfn from somewhere to begin with. Do the
>> bifurcated frames end up in two different a
On Mon, May 6, 2019 at 12:30 PM Andrew Cooper wrote:
>
> On 06/05/2019 18:41, Tamas K Lengyel wrote:
> > Hi Andrew,
> > thanks for helping brainstorming on this.
> >
> >> How exactly does DRAKVUF go about injecting silent breakpoints? It
> >> obviously has to allocate a new gfn from somewhere to
flight 135687 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135687/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 135437
test-armhf-armhf-libvirt-raw 13 saveresto
flight 135689 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135689/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fbb0ec7ea4c0d1e9e397fe898fb7d69de0779084
baseline version:
ovmf d027412258875cee48597
flight 135683 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135683/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow216 guest-saverestore.2 fail like 135436
test-amd64-amd64-xl-qemuu-dmrest
flight 135690 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135690/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl7 xen-boot fail REGR. vs. 129313
test-arm64-arm64-exa
On 06/05/2019 17:32, Marek Marczykowski-Górecki wrote:
> On Mon, May 06, 2019 at 05:15:19PM +0200, Juergen Gross wrote:
>> On 06/05/2019 16:50, Marek Marczykowski-Górecki wrote:
>>> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
>>> index ccdffc0..b0f0f7e 100644
>>> --- a/xen/incl
flight 135711 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135711/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 135251
build-amd64-xsm
94 matches
Mail list logo
