[Xen-devel] [xen-unstable test] 101215: tolerable FAIL - PUSHED

flight 101215 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/101215/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101209

[Xen-devel] [ovmf test] 101217: all pass - PUSHED

flight 101217 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/101217/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf dab62c5ec8a88def3ee99c04d644720cb201de08 baseline version: ovmf

[Xen-devel] [PATCH v2 10/10] xl: allow to set the ratelimit value online for Credit2

Last part of the wiring necessary for allowing to change the value of the ratelimit_us parameter online, for Credit2 (like it is already for Credit1). Signed-off-by: Dario Faggioli Reviewed-by: George Dunlap --- Cc: Ian Jackson

[Xen-devel] [PATCH v2 09/10] libxl: allow to set the ratelimit value online for Credit2

This is the remaining part of the plumbing (the libxl one) necessary to be able to change the value of the ratelimit_us parameter online, for Credit2 (like it is already for Credit1). Note that, so far, we were rejecting (for Credit1) a new value of zero, despite it is a pretty nice way to ask

[Xen-devel] [PATCH v2 05/10] xen: credit2: implement yield()

When a vcpu explicitly yields it is usually giving us an advice of "let someone else run and come back to me in a bit." Credit2 isn't, so far, doing anything when a vcpu yields, which means an yield is basically a NOP (well, actually, it's pure overhead, as it causes the scheduler kick in, but

[Xen-devel] [PATCH v2 08/10] libxl: fix coding style of credit1 parameters related functions

More specifically, the the error handling path is made compliant with libxl's codying style. No functional change intended. Signed-off-by: Dario Faggioli --- Cc: Ian Jackson Cc: Wei Liu Cc: George Dunlap

[Xen-devel] [PATCH v2 06/10] xen: tracing: add trace records for schedule and rate-limiting.

As far as {csched, csched2, rt}_schedule() are concerned, an "empty" event, would already make it easier to read and understand a trace. But while there, add a few useful information, like if the cpu that is going through the scheduler has been tickled or not, if it is currently idle, etc (they

[Xen-devel] [PATCH v2 07/10] tools: tracing: handle more scheduling related events.

There are some scheduling related trace records that are not being taken care of (and hence only dumped as raw records). Some of them are being introduced in this series, while other were just neglected by previous patches. Add support for them. Signed-off-by: Dario Faggioli

[Xen-devel] [PATCH v2 04/10] xen: credit2: only reset credit on reset condition

The condition for a Credit2 scheduling epoch coming to an end is that the vcpu at the front of the runqueue has negative credits. However, it is possible, that runq_candidate() does not actually return to the scheduler the first vcpu in the runqueue (e.g., because such vcpu can't run on the cpu

[Xen-devel] [PATCH v2 02/10] xen: credit1: don't rate limit context switches in case of yields

Rate limiting has been primarily introduced to avoid too heavy context switch rate due to interrupts, and, in general, asynchronous events. If a vcpu "voluntarily" yields, we really should let it give up the cpu for a while. In fact, it may be that it is yielding because it's about to start

[Xen-devel] [PATCH v2 01/10] xen: credit1: return the 'time remaining to the limit' as next timeslice.

If vcpu x has run for 200us, and sched_ratelimit_us is 1000us, continue running x _but_ return 1000us-200us as the next time slice. This way, next scheduling point will happen in 800us, i.e., exactly at the point when x crosses the threshold, and can be descheduled (if appropriate). Right now

[Xen-devel] [PATCH v2 03/10] xen: credit2: make tickling more deterministic

Right now, the following scenario can occurr: - upon vcpu v wakeup, v itself is put in the runqueue, and pcpu X is tickled; - pcpu Y schedules (for whatever reason), sees v in the runqueue and picks it up. This may seem ok (or even a good thing), but it's not. In fact, if runq_tickle()

[Xen-devel] [PATCH v2 00/10] sched: Credit1 and Credit2 improvements... but *NO* soft-affinity for Credit2!

Hey, This is v2 of my Credit1 and Credit2 improvements series. First posting is here: https://lists.xen.org/archives/html/xen-devel/2016-08/msg02183.html Now, couple of things: - some of the patches have been applied already out of v1; - I've reshuffled the remaining patches a bit, mostly

Re: [Xen-devel] [PATCH 05/24] xen: credit2: make tickling more deterministic

On Tue, 2016-09-13 at 12:28 +0100, George Dunlap wrote: > On 17/08/16 18:18, Dario Faggioli wrote: > >  > diff --git a/xen/common/sched_credit2.c > > @@ -2233,7 +2241,8 @@ void __dump_execstate(void *unused); > >  static struct csched2_vcpu * > >  runq_candidate(struct csched2_runqueue_data *rqd,

[Xen-devel] [Resend PATCH 2/2] Xen/timer: Process softirq during dumping timer info

Dumping timer info may run for a long time on the huge machine with a lot of physical cpus. To avoid triggering NMI watchdog, add process_pending_softirqs() in the loop of dumping timer info. Signed-off-by: Lan Tianyu --- xen/common/timer.c |1 + 1 files changed, 1

[Xen-devel] [Resend PATCH 0/2] Xen: Fix Xen hypervisor panic during dumping timer info on huge machine.

Resend because the patchset seems to miss xen devel maillist. This patchset is to fix triggering NMI watchdog during dump timer info on the huge machine with a mount of physical cpus. Detail please see change log of Patch 1. Previous discussion: https://patchwork.kernel.org/patch/9328449/ Lan

[Xen-devel] [Resend PATCH 1/2] Xen/Keyhandler: Make keyhandler always run in tasklet

Keyhandler may run for a long time in a timer handler on the large machine with a lot of physical cpus(E,G keyhandler for dumping timer info) when serial port driver works in the poll mode. When timer interrupt arrives, timer subsystem runs all timer handlers before programming next timer

[Xen-devel] [qemu-mainline test] 101213: tolerable FAIL - PUSHED

flight 101213 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/101213/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101203 test-amd64-amd64-xl-rtds

Re: [Xen-devel] [PATCH 14/24] libxl: allow to set the ratelimit value online for Credit2

On Mon, 2016-08-22 at 10:28 +0100, Ian Jackson wrote: > Dario Faggioli writes ("[PATCH 14/24] libxl: allow to set the > ratelimit value online for Credit2"): > ... > > > > -rc = xc_sched_credit_params_set(ctx->xch, poolid, ); > > -if ( rc < 0 ) { > > -LOGE(ERROR, "setting sched

[Xen-devel] [xen-unstable test] 101209: tolerable FAIL - PUSHED

flight 101209 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/101209/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 9 debian-install fail blocked in 101182

[Xen-devel] [PATCH v9 10/13] x86/setup: use XEN_IMG_OFFSET instead of...

..calculating its value during runtime. Signed-off-by: Daniel Kiper Acked-by: Jan Beulich --- xen/arch/x86/setup.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index

[Xen-devel] [PATCH v9 07/13] x86: add multiboot2 protocol support for EFI platforms

This way Xen can be loaded on EFI platforms using GRUB2 and other boot loaders which support multiboot2 protocol. Signed-off-by: Daniel Kiper --- v9 - suggestions/fixes: - use .L labels instead of numeric ones in multiboot2 data scanning loops (suggested by Jan

[Xen-devel] [PATCH v9 08/13] x86/boot: implement early command line parser in C

Current early command line parser implementation in assembler is very difficult to change to relocatable stuff using segment registers. This requires a lot of changes in very weird and fragile code. So, reimplement this functionality in C. This way code will be relocatable out of the box (without

[Xen-devel] [PATCH v9 13/13] x86: add multiboot2 protocol support for relocatable images

Add multiboot2 protocol support for relocatable images. Only GRUB2 with "multiboot2: Add support for relocatable images" patch understands that feature. Older multiboot protocol (regardless of version) compatible loaders ignore it and everything works as usual. Signed-off-by: Daniel Kiper

[Xen-devel] [PATCH v9 12/13] x86/boot: rename sym_phys() to sym_offs()

This way macro name better describes its function. Currently it is used to calculate symbol offset in relation to the beginning of Xen image mapping. However, value returned by sym_offs() for a given symbol is not always equal its physical address. There is no functional change. Suggested-by:

[Xen-devel] [PATCH v9 09/13] x86: change default load address from 1 MiB to 2 MiB

Subsequent patches introducing relocatable early boot code play with page tables using 2 MiB huge pages. If load address is not aligned at 2 MiB then code touching such page tables must have special cases for start and end of Xen image memory region. So, let's make life easier and move default

[Xen-devel] [PATCH v9 11/13] x86: make Xen early boot code relocatable

Every multiboot protocol (regardless of version) compatible image must specify its load address (in ELF or multiboot header). Multiboot protocol compatible loader have to load image at specified address. However, there is no guarantee that the requested memory region (in case of Xen it starts at 2

[Xen-devel] [PATCH v9 03/13] x86: allow EFI reboot method neither on EFI platforms...

..nor EFI platforms with runtime services enabled. Suggested-by: Jan Beulich Signed-off-by: Daniel Kiper Acked-by: Jan Beulich --- v6 - suggestions/fixes: - move this commit behind "efi: create efi_enabled()" commit

[Xen-devel] [PATCH v9 04/13] x86: properly calculate xen ELF end of image address

This patch is prereq for "efi: build xen.gz with EFI code" patch which adds, among others, xen/arch/x86/efi/relocs-dummy.S to xen.gz output. Below there is a description why it is needed. Currently xen ELF end of image address is calculated using first line from "nm -nr xen/xen-syms" output.

[Xen-devel] [PATCH v9 02/13] efi: create efi_enabled()

First of all we need to differentiate between legacy BIOS and EFI platforms during runtime, not during build, because one image will have legacy and EFI code and can be executed on both platforms. Additionally, we need more fine grained knowledge about EFI environment and check for EFI platform

[Xen-devel] [PATCH v9 00/13] x86: multiboot2 protocol support

Hi, I am sending ninth version of multiboot2 protocol support for legacy BIOS and EFI platforms. This patch series release contains fixes for all known issues. The final goal is xen.efi binary file which could be loaded by EFI loader, multiboot (v1) protocol (only on legacy BIOS platforms) and

[Xen-devel] [PATCH v9 05/13] efi: build xen.gz with EFI code

Build xen.gz with EFI code. We need this to support multiboot2 protocol on EFI platforms. If we wish to load non-ELF file using multiboot (v1) or multiboot2 then it must contain "linear" (or "flat") representation of code and data. This is requirement of both boot protocols. Currently, PE file

[Xen-devel] [PATCH v9 06/13] efi: create new early memory allocator

There is a problem with place_string() which is used as early memory allocator. It gets memory chunks starting from start symbol and goes down. Sadly this does not work when Xen is loaded using multiboot2 protocol because then the start lives on 1 MiB address and we should not allocate a memory

[Xen-devel] [PATCH v9 01/13] x86: add multiboot2 protocol support

Add multiboot2 protocol support. Alter min memory limit handling as we now may not find it from either multiboot (v1) or multiboot2. This way we are laying the foundation for EFI + GRUB2 + Xen development. Signed-off-by: Daniel Kiper Reviewed-by: Jan Beulich

Re: [Xen-devel] [PATCH v2 15/16] x86/PV: use generic emulator for privileged instruction handling

On 28/09/16 09:18, Jan Beulich wrote: > There's a new emulator return code being added to allow bypassing > certain operations (see the code comment). Its handling in the epilogue > code involves moving the raising of the single step trap until after > registers were updated. This should probably

Re: [Xen-devel] [PATCH v2 16/16] x86emul: don't assume a memory operand

On 28/09/16 09:19, Jan Beulich wrote: > Especially for x86_insn_operand_ea() to return dependable segment > information even when the caller didn't consider applicability, we > shouldn't have ea.type start out as OP_MEM. Make it OP_NONE instead, > and set it to OP_MEM when we actually encounter

Re: [Xen-devel] [PATCH 10/24] xen: tracing: improve Credit2's tickle_check and burn_credits records

On Thu, 2016-09-29 at 18:28 +0100, George Dunlap wrote: > On 29/09/16 18:23, Dario Faggioli wrote: > > In that case, knowing where a certain vcpu that we're asking to > > burn > > its credit is running, may mean going quite a bit up in the trace, > > to > > find its last context switch/runstate

[Xen-devel] [xen-unstable-smoke test] 101212: tolerable all pass - PUSHED

flight 101212 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/101212/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

Re: [Xen-devel] [PATCH v2 14/16] x86emul: sort opcode 0f01 special case switch() statement

On 28/09/16 09:18, Jan Beulich wrote: > Sort the special case opcode 0f01 entries numerically, insert blank > lines between each of the cases, and properly place opening braces. > > No functional change. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper

Re: [Xen-devel] [PATCH v2 13/16] x86emul: support XSETBV

On 28/09/16 09:17, Jan Beulich wrote: > This is a prereq for switching PV privileged op emulation to the > generic instruction emulator. Since handle_xsetbv() is already capable > of dealing with all guest kinds, avoid introducing another hook here. > > Signed-off-by: Jan Beulich

Re: [Xen-devel] [PATCH v2 12/16] x86/PV: split out dealing with MSRs from privileged instruction handling

On 28/09/16 09:16, Jan Beulich wrote: > This is in preparation for using the generic emulator here. > > Signed-off-by: Jan Beulich This looks like only code motion, so Reviewed-by: Andrew Cooper There is some rather unhelpful behaviour with the

Re: [Xen-devel] [PATCH v2 11/16] x86/PV: split out dealing with DRn from privileged instruction handling

On 28/09/16 09:15, Jan Beulich wrote: > This is in preparation for using the generic emulator here. > > Some care is needed temporarily to not unduly alter guest register > state: The local variable "res" can only go away once this code got > fully switched over to using x86_emulate(). > > Also

Re: [Xen-devel] [PATCH v2 10/16] x86/PV: split out dealing with CRn from privileged instruction handling

On 28/09/16 09:14, Jan Beulich wrote: > This is in preparation for using the generic emulator here. > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/traps.c > +++ b/xen/arch/x86/traps.c > @@ -2255,6 +2255,107 @@ unsigned long guest_to_host_gpr_switch(u > > void

Re: [Xen-devel] [PATCH v2 09/16] x86/32on64: use generic instruction decoding for call gate emulation

On 28/09/16 09:13, Jan Beulich wrote: > @@ -3204,179 +3285,59 @@ static void emulate_gate_op(struct cpu_u > return; > } > > -op_bytes = op_default = ar & _SEGMENT_DB ? 4 : 2; > -ad_default = ad_bytes = op_default; > -opnd_sel = opnd_off = 0; > -jump = -1; > -for

Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] xen: add qemu device for each pvusb backend

Gerd Hoffmann writes: > Hi, > >> > Hmm, I think the xen core needs better QOM support ... >> > >> > struct XenDevice should have a DeviceState element, so it can be used as >> > device object directly instead of attaching a device object like >> > this ... >> >> Hmm,

Re: [Xen-devel] [PATCH] pub-headers: reduce C99 dependencies

On Thu, Sep 29, 2016 at 12:22:37PM -0700, Julien Grall wrote: > > > On 29/09/2016 12:11, Julien Grall wrote: > >Hi Jan, > > > >On 28/09/2016 23:04, Jan Beulich wrote: > >On 28.09.16 at 21:42, wrote: > >>>Hi Jan, > >>> > >>>On 28/09/2016 05:00, Jan Beulich wrote: >

Re: [Xen-devel] [PATCH v2 08/16] SVM: use generic instruction decoding

On 28/09/16 09:13, Jan Beulich wrote: > ... instead of custom handling. To facilitate this break out init code > from _hvm_emulate_one() into the new hvm_emulate_init(), and make > hvmemul_insn_fetch( globally available. ) > int __get_instruction_length_from_list(struct vcpu *v, >

Re: [Xen-devel] [PATCH] pub-headers: reduce C99 dependencies

On 29/09/2016 12:11, Julien Grall wrote: Hi Jan, On 28/09/2016 23:04, Jan Beulich wrote: On 28.09.16 at 21:42, wrote: Hi Jan, On 28/09/2016 05:00, Jan Beulich wrote: For consumers not using (fully) C99-aware compilers, limit the number of places where tweaking of

[Xen-devel] [xtf test] 101211: all pass - PUSHED

flight 101211 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/101211/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf 50b7556924ad173285f4116dc9e0937600bf5bee baseline version: xtf

Re: [Xen-devel] [PATCH] pub-headers: reduce C99 dependencies

Hi Jan, On 28/09/2016 05:00, Jan Beulich wrote: For consumers not using (fully) C99-aware compilers, limit the number of places where tweaking of the headers would be necessary: Introduce and use xen_mk_ullong(), allowing its helper macro to be overridden at once. For now don't touch

Re: [Xen-devel] [PATCH] pub-headers: reduce C99 dependencies

Hi Jan, On 28/09/2016 23:04, Jan Beulich wrote: On 28.09.16 at 21:42, wrote: Hi Jan, On 28/09/2016 05:00, Jan Beulich wrote: For consumers not using (fully) C99-aware compilers, limit the number of places where tweaking of the headers would be necessary: Introduce and

Re: [Xen-devel] [PATCH] x86emul: fix {,i}mul and {,i}div

On Thu, Sep 29, 2016 at 07:08:10AM -0600, Jan Beulich wrote: > Commit a3db233ede ("x86emul: use DstEax also for {,I}{MUL,DIV}") went > a little too far: DstEax and SrcEax weren't really meant to be used > together with ModRM - they assume modrm_reg remains zero by the time > the destination /

Re: [Xen-devel] [PATCH v5] vm_event: Implement ARM SMC events

On Wed, 28 Sep 2016, Tamas K Lengyel wrote: > The ARM SMC instructions are already configured to trap to Xen by default. In > this patch we allow a user-space process in a privileged domain to receive > notification of when such event happens through the vm_event subsystem by > introducing the

Re: [Xen-devel] [PATCH] x86emul: fix {,i}mul and {,i}div

On 29/09/16 14:08, Jan Beulich wrote: > Commit a3db233ede ("x86emul: use DstEax also for {,I}{MUL,DIV}") went > a little too far: DstEax and SrcEax weren't really meant to be used > together with ModRM - they assume modrm_reg remains zero by the time > the destination / source register pointer

Re: [Xen-devel] qdevification of xen_disk

Hi Kevin, I agree with you, and if you would be so kind to send the patches, even untested, they would be much appreciated. Anthony or I will make sure to test them appropriately and fix them, if they turn out to be incomplete or partially broken. Would that be OK? Cheers, Stefano P.S. FYI Xen

Re: [Xen-devel] [PATCH] x86emul: simplify LEAVE handling

On 29/09/16 14:08, Jan Beulich wrote: > There's no 1-byte operand size case to take care of here, and there's > no point doing the first writeback using dst fields - we can read rBP > and write rSP directly. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper

Re: [Xen-devel] [PATCH 10/24] xen: tracing: improve Credit2's tickle_check and burn_credits records

On 29/09/16 18:23, Dario Faggioli wrote: > On Tue, 2016-09-20 at 15:35 +0100, George Dunlap wrote: >> On 17/08/16 18:18, Dario Faggioli wrote: >>> >>> In both Credit2's trace records relative to checking >>> whether we want to preempt a vcpu (in runq_tickle()), >>> and to credits being burn, make

Re: [Xen-devel] [PATCH 10/24] xen: tracing: improve Credit2's tickle_check and burn_credits records

On Tue, 2016-09-20 at 15:35 +0100, George Dunlap wrote: > On 17/08/16 18:18, Dario Faggioli wrote: > > > > In both Credit2's trace records relative to checking > > whether we want to preempt a vcpu (in runq_tickle()), > > and to credits being burn, make it explicit on which > > pcpu the vcpu

Re: [Xen-devel] [PATCH v2 06/30] x86/paging: introduce paging_set_allocation

On Thu, Sep 29, 2016 at 10:12:12AM -0600, Jan Beulich wrote: > >>> On 29.09.16 at 16:51, wrote: > > On Thu, Sep 29, 2016 at 04:51:42AM -0600, Jan Beulich wrote: > >> >>> On 27.09.16 at 17:57, wrote: > >> > @@ -1383,15 +1382,25 @@ int __init

Re: [Xen-devel] [PATCH 07/24] xen: sched: don't rate limit context switches in case of yields

On Tue, 2016-09-20 at 14:32 +0100, George Dunlap wrote: > On 17/08/16 18:18, Dario Faggioli wrote: > > diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c > > @@ -1771,9 +1771,18 @@ csched_schedule( > >   *   cpu and steal it. > >   */ > >   > > -/* If we have schedule

[Xen-devel] qdevification of xen_disk

Hi Stefano and all, while working on some part of the QEMU block layer infrastructure that requires going from a BlockBackend to the qdev DeviceState, I noticed that xen_disk is still not qdevified after all the years. It's the last device, and has been for a while, that is blocking the necessary

Re: [Xen-devel] [PATCH v2 08/30] xen/x86: do the PCI scan unconditionally

>>> On 29.09.16 at 17:11, wrote: > On Thu, Sep 29, 2016 at 07:55:00AM -0600, Jan Beulich wrote: >> >>> On 27.09.16 at 17:57, wrote: >> > Instead of being tied to the presence of an IOMMU >> >> At the very least I'd expect the "why" aspect to get

Re: [Xen-devel] [PATCH v2 06/30] x86/paging: introduce paging_set_allocation

>>> On 29.09.16 at 16:51, wrote: > On Thu, Sep 29, 2016 at 04:51:42AM -0600, Jan Beulich wrote: >> >>> On 27.09.16 at 17:57, wrote: >> > @@ -1383,15 +1382,25 @@ int __init construct_dom0( >> > nr_pages); >> > } >> > >>

Re: [Xen-devel] [PATCH v2 04/30] xen/x86: allow calling {sh/hap}_set_allocation with the idle domain

>>> On 29.09.16 at 16:37, wrote: > On Thu, Sep 29, 2016 at 04:43:07AM -0600, Jan Beulich wrote: >> >>> On 27.09.16 at 17:56, wrote: >> > --- a/xen/arch/x86/mm/hap/hap.c >> > +++ b/xen/arch/x86/mm/hap/hap.c >> > @@ -379,7 +379,9 @@

Re: [Xen-devel] [PATCH v2 03/30] xen/x86: fix parameters and return value of *_set_allocation functions

>>> On 29.09.16 at 16:33, wrote: > On Thu, Sep 29, 2016 at 04:39:02AM -0600, Jan Beulich wrote: >> >>> On 27.09.16 at 17:56, wrote: >> > Return should be an int, and the number of pages should be an unsigned >> > long. >> >> I can see the former, but

Re: [Xen-devel] [PATCH v2 02/30] xen/x86: remove XENFEAT_hvm_pirqs for PVHv2 guests

>>> On 29.09.16 at 16:17, wrote: > On Wed, Sep 28, 2016 at 10:03:21AM -0600, Jan Beulich wrote: >> >>> On 27.09.16 at 17:56, wrote: >> > On PVHv2 guests we explicitly want to use native methods for routing >> > interrupts. >> > >> > Introduce a new

Re: [Xen-devel] [PATCH 06/24] xen: credit2: implement yield()

On Tue, 2016-09-13 at 14:33 +0100, George Dunlap wrote: > On 17/08/16 18:18, Dario Faggioli wrote: > > Alternatively, we can actually _subtract_ some credits to a > > yielding vcpu. > > That will sort of make the effect of a call to yield last in time. > > But normally we want the yield to be

[Xen-devel] [ovmf test] 101206: all pass - PUSHED

flight 101206 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/101206/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 84bc72fb7ddaa26105bfe5bf36115099da1e60b1 baseline version: ovmf

Re: [Xen-devel] [PATCH v2 07/30] xen/x86: split the setup of Dom0 permissions to a function

On Thu, Sep 29, 2016 at 07:47:22AM -0600, Jan Beulich wrote: > >>> On 27.09.16 at 17:57, wrote: > > So that it can also be used by the PVH-specific domain builder. This is just > > code motion, it should not introduce any functional change. > > > > Signed-off-by: Roger Pau

[Xen-devel] [qemu-mainline test] 101203: tolerable FAIL - PUSHED

flight 101203 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/101203/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101186 test-amd64-amd64-xl-rtds

Re: [Xen-devel] [PATCH 2/2] xen: add qemu device for each pvusb backend

Hi, > > Hmm, I think the xen core needs better QOM support ... > > > > struct XenDevice should have a DeviceState element, so it can be used as > > device object directly instead of attaching a device object like > > this ... > > Hmm, interesting idea. The device object could even be added in

Re: [Xen-devel] [PATCH v2 08/30] xen/x86: do the PCI scan unconditionally

On Thu, Sep 29, 2016 at 07:55:00AM -0600, Jan Beulich wrote: > >>> On 27.09.16 at 17:57, wrote: > > Instead of being tied to the presence of an IOMMU > > At the very least I'd expect the "why" aspect to get mentioned > here. TBH, it seems simpler to have it there rather

[Xen-devel] [xen-unstable test] 101202: regressions - FAIL

flight 101202 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/101202/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 101182 Regressions which

[Xen-devel] [libvirt test] 101200: tolerable FAIL - PUSHED

flight 101200 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/101200/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14

Re: [Xen-devel] [PATCH 2/2] xen: add qemu device for each pvusb backend

On 27/09/16 11:08, Gerd Hoffmann wrote: > Hi, > >> struct usbback_info { >> struct XenDevice xendev; /* must be first */ >> +char id[24]; >> +struct USBBACKDevice *dev; >> USBBus bus; >> void

Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] xen: add qemu device for each pvusb backend

On 27/09/16 11:00, Daniel P. Berrange wrote: > On Mon, Sep 26, 2016 at 02:43:57PM +0200, Juergen Gross wrote: >> In order to be able to specify to which pvusb controller a new pvusb >> device should be added we need a qemu device for each pvusb controller >> with an associated id. >> >> Add such a

Re: [Xen-devel] [PATCH 1/2] xen: add an own bus for xen backend devices

On 27/09/16 10:53, Gerd Hoffmann wrote: > On Mo, 2016-09-26 at 14:43 +0200, Juergen Gross wrote: >> Add a bus for Xen backend devices in order to be able to establish a >> dedicated device path for pluggable devices. > > Looks sane to me. Can take this through the usb queue if I get an ack >

Re: [Xen-devel] [PATCH 0/2] Xen pvUSB correction

On 27/09/16 10:51, Gerd Hoffmann wrote: > On Mo, 2016-09-26 at 14:43 +0200, Juergen Gross wrote: >> Trying to use pvUSB in a Xen guest with a qemu emulated USB controller >> will crash qemu as it tries to attach a pvUSB device to the emulated >> controller. > > Hmm. --verbose please. > > While

Re: [Xen-devel] [PATCH v2 04/30] xen/x86: allow calling {sh/hap}_set_allocation with the idle domain

On Thu, Sep 29, 2016 at 04:43:07AM -0600, Jan Beulich wrote: > >>> On 27.09.16 at 17:56, wrote: > > --- a/xen/arch/x86/mm/hap/hap.c > > +++ b/xen/arch/x86/mm/hap/hap.c > > @@ -379,7 +379,9 @@ hap_set_allocation(struct domain *d, unsigned long > > pages, int *preempted) > >

Re: [Xen-devel] [PATCH v2 03/30] xen/x86: fix parameters and return value of *_set_allocation functions

On Thu, Sep 29, 2016 at 04:39:02AM -0600, Jan Beulich wrote: > >>> On 27.09.16 at 17:56, wrote: > > Return should be an int, and the number of pages should be an unsigned long. > > I can see the former, but why the latter? Acting on 32-bit quantities > is a little cheaper

Re: [Xen-devel] [PATCH v2 10/30] xen/x86: allow the emulated APICs to be enbled for the hardware domain

>>> On 27.09.16 at 17:57, wrote: > +static bool emulation_flags_ok(const struct domain *d, uint32_t emflags) > +{ > + > +if ( is_hvm_domain(d) ) > +{ > +if ( is_hardware_domain(d) && > + emflags != >

Re: [Xen-devel] [PATCH v2 09/30] x86/vtd: fix and simplify mapping RMRR regions

>>> On 27.09.16 at 17:57, wrote: > The current code used by Intel VTd will only map RMRR regions for the > hardware domain, but will fail to map RMRR regions for unprivileged domains > unless the page tables are shared between EPT and IOMMU. Okay, if that's the case it

Re: [Xen-devel] [PATCH v2 02/30] xen/x86: remove XENFEAT_hvm_pirqs for PVHv2 guests

On Wed, Sep 28, 2016 at 10:03:21AM -0600, Jan Beulich wrote: > >>> On 27.09.16 at 17:56, wrote: > > On PVHv2 guests we explicitly want to use native methods for routing > > interrupts. > > > > Introduce a new XEN_X86_EMU_USE_PIRQ to notify Xen whether a HVM guest can > >

Re: [Xen-devel] [PATCH v2 08/30] xen/x86: do the PCI scan unconditionally

>>> On 27.09.16 at 17:57, wrote: > Instead of being tied to the presence of an IOMMU At the very least I'd expect the "why" aspect to get mentioned here. > --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c > +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c > @@ -219,7

[Xen-devel] [xen-4.7-testing test] 101197: tolerable FAIL - PUSHED

flight 101197 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/101197/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101076

[Xen-devel] Adding new custom devices to Xen via QEMU

Hello, My name is Jason Dickens and I'm a Research Scientist here at GrammaTech. Some of our research involves securing hypervisors and we have needed to add to and/or modify Xen. I have been successful in modifying the source for various purposes, but my question now is about devices. We

[Xen-devel] [xen-4.6-testing baseline-only test] 67782: regressions - FAIL

This run is configured for baseline tests only. flight 67782 xen-4.6-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67782/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-multivcpu 6 xen-boot

[Xen-devel] [PATCH] x86emul: simplify LEAVE handling

There's no 1-byte operand size case to take care of here, and there's no point doing the first writeback using dst fields - we can read rBP and write rSP directly. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++

[Xen-devel] [PATCH] x86emul: fix {,i}mul and {,i}div

Commit a3db233ede ("x86emul: use DstEax also for {,I}{MUL,DIV}") went a little too far: DstEax and SrcEax weren't really meant to be used together with ModRM - they assume modrm_reg remains zero by the time the destination / source register pointer gets calculated. Don't fully undo that commit

Re: [Xen-devel] [PATCH v2 01/30] xen/x86: move setup of the VM86 TSS to the domain builder

On Wed, Sep 28, 2016 at 09:35:21AM -0600, Jan Beulich wrote: > >>> On 27.09.16 at 17:56, wrote: > > This is also required for PVHv2 guests if they want to use real-mode, and > > hvmloader is not executed for those kind of guests. > > While the intention is fine, I'm not

[Xen-devel] [distros-debian-wheezy test] 67783: all pass

flight 67783 distros-debian-wheezy real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67783/ Perfect :-) All tests in this flight passed as required baseline version: flight 67745 jobs: build-amd64 pass

[Xen-devel] [xen-unstable-smoke test] 101207: tolerable all pass - PUSHED

flight 101207 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/101207/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

Re: [Xen-devel] [PATCH v8 06/13] efi: create new early memory allocator

On Thu, Sep 29, 2016 at 10:08:30AM +0200, Daniel Kiper wrote: > On Thu, Sep 29, 2016 at 01:40:44AM -0600, Jan Beulich wrote: > > >>> On 29.09.16 at 00:51, wrote: > > > v8 - suggestions/fixes: > > >- disable whole ebmalloc machinery on ARM platforms, > > > > This is

Re: [Xen-devel] Regression introduced by a3db233 x86emul: use DstEax also for {, I}{MUL, DIV

>>> On 29.09.16 at 11:34, wrote: On 29.09.16 at 11:11, wrote: >> The commit a3db233 x86emul: use DstEax also for {,I}{MUL,DIV} >> introduces an regression when doing SR-IOV passthrough. > > I'll see if I can repro, Actually, I can see some

Re: [Xen-devel] [PATCH 18/24] xen: credit2: soft-affinity awareness fallback_cpu() and cpu_pick()

On 17/08/16 18:19, Dario Faggioli wrote: > For get_fallback_cpu(), by putting in place the "usual" > two steps (soft affinity step and hard affinity step) > loop. We just move the core logic of the function inside > the body of the loop itself. > > For csched2_cpu_pick(), what is important is to

Re: [Xen-devel] [PATCH v2 06/30] x86/paging: introduce paging_set_allocation

>>> On 27.09.16 at 17:57, wrote: > @@ -1383,15 +1382,25 @@ int __init construct_dom0( > nr_pages); > } > > -if ( is_pvh_domain(d) ) > -hap_set_alloc_for_pvh_dom0(d, dom0_paging_pages(d, nr_pages)); > - > /* > * We

Re: [Xen-devel] [PATCH v2 2/2] hvmloader, pci: Don't try to relocate memory if 64-bit BAR is bigger than ~2GB

On Thu, Sep 29, 2016 at 03:36:00AM -0600, Jan Beulich wrote: > >>> On 29.09.16 at 11:23, wrote: > > On Thu, Sep 29, 2016 at 01:03:02AM -0600, Jan Beulich wrote: > >> >>> On 29.09.16 at 01:48, wrote: > >> > @@ -265,11 +266,30 @@ void pci_setup(void)

Re: [Xen-devel] [PATCH v2 05/30] xen/x86: assert that local_events_need_delivery is not called by the idle domain

>>> On 27.09.16 at 17:57, wrote: > It doesn't make sense since the idle domain doesn't receive any events. The change itself is fine, but I think it would help if the commit message made explicit why this is becoming relevant. Jan

Re: [Xen-devel] [PATCH v2 04/30] xen/x86: allow calling {sh/hap}_set_allocation with the idle domain

>>> On 27.09.16 at 17:56, wrote: > --- a/xen/arch/x86/mm/hap/hap.c > +++ b/xen/arch/x86/mm/hap/hap.c > @@ -379,7 +379,9 @@ hap_set_allocation(struct domain *d, unsigned long pages, > int *preempted) > break; > > /* Check to see if we need to yield

Re: [Xen-devel] [PATCH v2 07/16] x86emul: generate and make use of a canonical opcode representation

On 28/09/16 09:12, Jan Beulich wrote: > @@ -1732,13 +1745,35 @@ x86_decode_twobyte( > } > > static int > +x86_decode_0f38( > +struct x86_emulate_state *state, > +struct x86_emulate_ctxt *ctxt, > +const struct x86_emulate_ops *ops) > +{ > +switch ( ctxt->opcode &

  1   2   >