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

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

[Xen-devel] [ovmf baseline-only test] 67550: all pass

This run is configured for baseline tests only. flight 67550 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67550/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf fd4d9c6495109979eb17779e07666c7c11c79c6a baseline

Re: [Xen-devel] Xen virtual IOMMU high level design doc

On 8/17/2016 8:42 PM, Paul Durrant wrote: -Original Message- From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Lan, Tianyu Sent: 17 August 2016 13:06 To: Jan Beulich; Kevin Tian; Andrew Cooper; yang.zhang...@gmail.com; Jun Nakajima; Stefano Stabellini Cc: Anthony

Re: [Xen-devel] [PATCH 2/9] x86/mtrr: drop mtrr_if indirection

On 8/17/16 7:49 AM, Jan Beulich wrote: On 17.08.16 at 01:28, wrote: >> There can only ever be one mtrr_if now and that is the generic >> implementation > > This is only true when taking into consideration that cpu_has_mtrr > is #define-d to 1 right now. I'm not sure

Re: [Xen-devel] [PATCH 1/9] x86/mtrr: prefix fns with mtrr and drop static

On 8/17/16 7:36 AM, Jan Beulich wrote: On 17.08.16 at 01:28, wrote: >> For the functions that make up the interface to the MTRR code, drop the >> static keyword and prefix them all with mtrr for improved clarity when >> they're called outside this file. This also required

Re: [Xen-devel] [PATCH 08/24] xen: tracing: add trace records for schedule and rate-limiting.

On Wed, Aug 17, 2016 at 1:18 PM, Dario Faggioli wrote: > > 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

Re: [Xen-devel] [PATCH 00/24] sched: Credit1 and Credit2 improvements... and soft-affinity for Credit2!

On Wed, 2016-08-17 at 19:17 +0200, Dario Faggioli wrote: > The last 4 patches, still for Credit2, are optimizations, either wrt > existing > code, or wrt new code introduced in this series. I've chosen to keep > them > separate to make reviewing/understanding new code easier. In fact, > although >

Re: [Xen-devel] [PATCH 02/24] xen: credit1: fix mask to be used for tickling in Credit1

On Wed, 2016-08-17 at 19:17 +0200, Dario Faggioli wrote: > If there are idle pcpus inside the waking vcpu's > soft-affinity mask, we should really tickle one > of them (this is one of the purposes of the > __runq_tickle() function itself!), not just > any idle pcpu. > > The issue has been

Re: [Xen-devel] [PATCH 0/2] tools/libs: don't use alloca(3)

On Wed, 2016-08-17 at 15:33 +0100, Wei Liu wrote: > Wei Liu (2): >   libs/gnttab: do not use alloca(3) >   libs/foreignmemory: do not use alloca(3) > FWIW, both patches: Reviewed-by: Dario Faggioli Out of curiosity, I've tried to figure out what the advantage was in

Re: [Xen-devel] unable start xen in hikey

Hi Chen, My previous issue was resolved when i used hi6220-hikey.dtb from this source: https://github.com/kuscsik/device-linaro-hikey-kernel. When I download linux kernel, there doesn't seems to contain hi6220-hikey.dtb. But now it got stuck while loading Dom0 and below are log traces: (XEN)

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

flight 100533 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100533/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 6 xen-boot fail like 100481 build-amd64-rumpuserxen

[Xen-devel] [distros-debian-squeeze test] 67547: tolerable FAIL

flight 67547 distros-debian-squeeze real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67547/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like 66959

[Xen-devel] [linux-3.14 baseline-only test] 67546: tolerable FAIL

This run is configured for baseline tests only. flight 67546 linux-3.14 real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67546/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-i386-rumpuserxen6 xen-build

[Xen-devel] XSA 154 and ISA region (640K -> 1MB) WB cache instead of UC

Hey Jan, et. al., One of the interesting things about XSA 154 fix ("x86: enforce consistent cachability of MMIO mappings") is that when certain applications (mcelog) are trying to map /dev/mmap and lurk in ISA regions - we get: [ 49.399053] WARNING: CPU: 0 PID: 2471 at arch/x86/mm/pat.c:913

Re: [Xen-devel] [PATCH v1 9/9] livepatch: tests: Make them compile under ARM64

On 17/08/2016 20:57, Julien Grall wrote: > Hi Konrad, > > On 17/08/2016 20:00, Konrad Rzeszutek Wilk wrote: >> On Wed, Aug 17, 2016 at 07:29:12PM +0100, Julien Grall wrote: >>> On 15/08/16 00:07, Konrad Rzeszutek Wilk wrote: > > [...] > diff --git a/xen/common/Makefile b/xen/common/Makefile

Re: [Xen-devel] [PATCH v2 5/6] xen/arm: traps: Avoid unnecessary VA -> IPA translation in abort handlers

On 08/17/2016 06:11 AM, Julien Grall wrote: On 17/08/16 03:19, Shanker Donthineni wrote: Hi Julien, Hello Shanker, On 07/27/2016 12:09 PM, Julien Grall wrote: Translating a VA to a IPA is expensive. Currently, Xen is assuming that HPFAR_EL2 is only valid when the stage-2 data/instruction

Re: [Xen-devel] [PATCH v1 9/9] livepatch: tests: Make them compile under ARM64

Hi Konrad, On 17/08/2016 20:00, Konrad Rzeszutek Wilk wrote: On Wed, Aug 17, 2016 at 07:29:12PM +0100, Julien Grall wrote: On 15/08/16 00:07, Konrad Rzeszutek Wilk wrote: [...] diff --git a/xen/common/Makefile b/xen/common/Makefile index 22806b6..fe83653 100644 --- a/xen/common/Makefile

Re: [Xen-devel] [PATCH v1 6/9] livepatch: Initial ARM64 support.

Hi Konrad, On 17/08/2016 19:57, Konrad Rzeszutek Wilk wrote: +void arch_livepatch_apply_jmp(struct livepatch_func *func) +{ +uint32_t insn; +uint32_t *old_ptr; +uint32_t *new_ptr; + +BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->opaque)); +BUILD_BUG_ON(PATCH_INSN_SIZE !=

Re: [Xen-devel] [PATCH v1 6/9] livepatch: Initial ARM64 support.

On 17/08/2016 02:50, Konrad Rzeszutek Wilk wrote: +int arch_livepatch_perform_rela(struct livepatch_elf *elf, +const struct livepatch_elf_sec *base, +const struct livepatch_elf_sec *rela) +{ .. snip.. +switch (

Re: [Xen-devel] [PATCH v1 9/9] livepatch: tests: Make them compile under ARM64

On Wed, Aug 17, 2016 at 07:29:12PM +0100, Julien Grall wrote: > Hi Konrad, > > On 15/08/16 00:07, Konrad Rzeszutek Wilk wrote: > > We need to two things: > > 1) Wrap the platform-specific objcopy paramters in defines > > s/paramters/parameters/ > > >The input and output parmeters for

Re: [Xen-devel] [PATCH v1 6/9] livepatch: Initial ARM64 support.

> > +void arch_livepatch_apply_jmp(struct livepatch_func *func) > > +{ > > +uint32_t insn; > > +uint32_t *old_ptr; > > +uint32_t *new_ptr; > > + > > +BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->opaque)); > > +BUILD_BUG_ON(PATCH_INSN_SIZE != sizeof(insn)); > > + > > +

Re: [Xen-devel] [PATCH v1 6/9] livepatch: Initial ARM64 support.

Hi Konrad, On 15/08/16 00:07, Konrad Rzeszutek Wilk wrote: [...] diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c new file mode 100644 index 000..e348942 --- /dev/null +++ b/xen/arch/arm/arm64/livepatch.c @@ -0,0 +1,247 @@ +/* + * Copyright (c) 2016 Oracle

[Xen-devel] [PATCH] x86: Add a tboot Kconfig option

Allows for the conditional inclusion of tboot related functionality via Kconfig The default configuration for the new CONFIG_TBOOT option is 'y', so the behavior out of the box remains unchanged. The addition of the option allows advanced users to disable system behaviors associated with tboot

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

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

[Xen-devel] [PATCH 24/24] xen: credit2: try to avoid tickling cpus subject to ratelimiting

With context switching ratelimiting enabled, the following pattern is quite common in a scheduling trace: 0.000845622 |||.x||| d32768v12 csched2:runq_insert d0v13, position 0 0.000845831 |||.x||| d32768v12 csched2:runq_tickle_new d0v13, processor = 12, credit = 10135529

[Xen-devel] [PATCH 23/24] xen: credit2: optimize runq_tickle() a little bit

By not looking at the same cpu (to check whether we want to preempt who's running there) twice, if the vcpu being woken up has both soft and hard affinity. In fact, all the cpus that are part of both soft affinity and hard-affinity (of the waking vcpu) are checked during the soft-affinity

[Xen-devel] [PATCH 22/24] xen: credit2: "relax" CSCHED2_MAX_TIMER

Credit2 is already event based, rather than tick based. This means, the time at which the (i+1)-eth scheduling decision needs to happen is computed during the i-eth scheduling decision, and a timer is set accordingly. If there's nothing imminent (or, the most imminent event is really really

[Xen-devel] [PATCH 21/24] xen: credit2: optimize runq_candidate() a little bit

By factoring into one (at the top) all the checks to see whether current is the idle vcpu, and mark it as unlikely(). In fact, if current is idle, all the logic for dealing with yielding, context switching rate limiting and soft-affinity, is just pure overhead, and we better rush checking the

[Xen-devel] [PATCH 20/24] xen: credit2: kick away vcpus not running within their soft-affinity

If, during scheduling, we realize that the current vcpu is running outside of its own soft-affinity, it would be preferable to send it somewhere else. Of course, that may not be possible, and if we're too strict, we risk having vcpus sit in runqueues, even if there are idle pcpus (violating

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

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 find the runqueue with the least average load.

[Xen-devel] [PATCH 19/24] xen: credit2: soft-affinity awareness in load balancing

We want is soft-affinity to play a role in load balancing, i.e., when deciding whether or not to push this vcpu from here to there, and/or pull that other vcpu from there to here. A way of doing that, is considering the following (for both pushes and pulls, just with the roles of current an new

[Xen-devel] [PATCH 15/24] 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 --- Cc: Ian Jackson Cc: Wei Liu Cc:

[Xen-devel] [PATCH 17/24] xen: credit2: soft-affinity awareness in runq_tickle()

This is done by means of the "usual" two steps loop: - soft affinity balance step; - hard affinity balance step. The entire logic implemented in runq_tickle() is applied, during the first step, considering only the CPUs in the vcpu's soft affinity. In the second step, we fall back to use all

[Xen-devel] [PATCH 16/24] xen: sched: factor affinity helpers out of sched_credit.c

make it possible to use the various helpers from other schedulers, e.g., for implementing soft affinity within them. Since we are touching the code, also make it start using variables called v for struct_vcpu*, as it is preferrable. No functional change intended. Signed-off-by: Dario Faggioli

[Xen-devel] [PATCH 13/24] libxc: improve error handling of xc Credit1 and Credit2 helpers

In fact, libxc wrappers should, on error, set errno and return -1. Signed-off-by: Dario Faggioli --- Cc: George Dunlap Cc: Ian Jackson Cc: Wei Liu --- tools/libxc/xc_csched.c | 27

[Xen-devel] [PATCH 14/24] 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 12/24] xen: libxc: allow to set the ratelimit value online

The main purpose of the patch is to provide the xen-libxc plumbing necessary to be able to change the value of the ratelimit_us parameter online, for Credit2 (like it is already for Credit1). While there: - mention in the Xen logs when rate limiting was enables and is being disabled (and

[Xen-devel] [PATCH 11/24] 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 10/24] xen: tracing: improve Credit2's tickle_check and burn_credits records

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 being considered is running. Such information isn't currently available, not even by looking at on which pcpu the events

[Xen-devel] [PATCH 09/24] xen/tools: tracing: improve tracing of context switches.

Right now, two out of the three events related to context switch (that is TRC_SCHED_SWITCH_INFPREV and TRC_SCHED_SWITCH_INFNEXT) only report the domain id, and not the vcpu id. That's omitting a useful piece of information, and even if we be figured that out by looking at other records, that's

[Xen-devel] [PATCH 08/24] 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 07/24] xen: sched: don't rate limit context switches in case of yields

In both Credit1 and Credit2, if a vcpu yields, let it... well... yield! In fact, context switch rate limiting has been primarily introduced to avoid too heavy context switch rate due to interrupts, and, in general, asynchronous events. In a vcpu "voluntarily" yields, we really should let it give

[Xen-devel] [PATCH 06/24] 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 01/24] xen: credit1: small optimization in Credit1's tickling logic.

If, when vcpu x wakes up, there are no idle pcpus in x's soft-affinity, we just go ahead and look at its hard affinity. This basically means that, if, in __runq_tickle(), new_idlers_empty is true, balance_step is equal to CSCHED_BALANCE_HARD_AFFINITY, and that calling csched_balance_cpumask() for

[Xen-devel] [PATCH 05/24] 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 04/24] xen: credit2: properly schedule migration of a running vcpu.

If wanting to migrate a vcpu that is actually running, we need to ask the scheduler to chime in as soon as possible, to have the vcpu itself stopped and actually moved. Make sure this happens by, after setting all the relevant flags, raising the scheduler softirq. Signed-off-by: Dario Faggioli

[Xen-devel] [PATCH 03/24] 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 02/24] xen: credit1: fix mask to be used for tickling in Credit1

If there are idle pcpus inside the waking vcpu's soft-affinity mask, we should really tickle one of them (this is one of the purposes of the __runq_tickle() function itself!), not just any idle pcpu. The issue has been introduced in 02ea5031825d ("credit1: properly deal with pCPUs not in any

[Xen-devel] [PATCH 00/24] sched: Credit1 and Credit2 improvements... and soft-affinity for Credit2!

Hi everyone, Here's another rather big scheduler-related series. The most of the content (as usual, lately) is about Credit2, but there are other things, about tracing and also about Credit1. In fact, this patch series introduces soft-affinity support for Credit2. The first 3 patches are indeed

Re: [Xen-devel] [PATCH v1 6/9] livepatch: Initial ARM64 support.

Hi Konrad, On 15/08/16 16:17, Julien Grall wrote: On 15/08/2016 01:07, Konrad Rzeszutek Wilk wrote: +case R_AARCH64_ADR_PREL_PG_HI21: +val = (val & ~0xfff) - ((u64)dest & ~0xfff); +err = reloc_insn_imm(dest, val, 12, 21, AARCH64_INSN_IMM_ADR); +

Re: [Xen-devel] [PATCH] ns16550: mask transmit holding register empty interrupt when tx is stopped

On Wed, Aug 17, 2016 at 10:29 AM, Jan Beulich wrote: On 17.08.16 at 16:02, wrote: >> From: Chris Patterson >> >> The uart generates an interrupt whenever the transmit holding register is >> empty and UART_IER_ETHREI is set in

Re: [Xen-devel] [PATCH v1 4/9] arm/mm: Introduce modify_xen_mappings

Hi Konrad, On 15/08/16 00:07, Konrad Rzeszutek Wilk wrote: Which is only used by Livepatch code. The purpose behind this call is to modify the page table entries flags. Specifically the .ro and .nx flags. The current mechanism puts cache attributes in the flags and the .ro and .nx are locked

Re: [Xen-devel] [PATCH v1 3/9] x86/arm64: Move the ALT_[ORIG|REPL]_PTR macros to header files.

Hi Konrad, On 15/08/16 00:07, Konrad Rzeszutek Wilk wrote: That way common code can use the same macro to access the most common attributes without much #ifdef. Take advantage of it right away in the livepatch code. Signed-off-by: Konrad Rzeszutek Wilk --- Cc:

Re: [Xen-devel] [PATCH v4 12/19] efi: introduce EFI_RS to ease control on runtime services usage

>>> On 06.08.16 at 01:04, wrote: Apart from the question of this probably better getting merged with the previous patch ... > --- a/xen/common/efi/boot.c > +++ b/xen/common/efi/boot.c > @@ -936,6 +936,10 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE >

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

flight 100535 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/100535/ 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 v4 11/19] efi: create efi_enabled()

>>> On 06.08.16 at 01:04, wrote: > --- a/xen/arch/x86/domain_page.c > +++ b/xen/arch/x86/domain_page.c > @@ -36,7 +36,7 @@ static inline struct vcpu *mapcache_current_vcpu(void) > * domain's page tables but current may point at another domain's VCPU. > *

Re: [Xen-devel] [PATCH v4 10/19] efi: move efi struct initialization to xen/common/lib.c

>>> On 06.08.16 at 01:04, wrote: > A subsequent patch adds efi struct flags member which is used > during runtime to differentiate between legacy BIOS and EFI > platforms and multiboot2 and EFI native loader. So, efi symbol > have to proper representation in ELF and PE

Re: [Xen-devel] [PATCH v4 09/19] x86: add multiboot2 protocol support

>>> On 06.08.16 at 01:04, wrote: > @@ -106,3 +121,119 @@ multiboot_info_t __stdcall *reloc(u32 mbi_in, u32 > trampoline) > > return mbi_out; > } > + > +static multiboot_info_t *mbi2_mbi(u32 mbi_in) > +{ > +const multiboot2_memory_map_t *mmap_src; > +const

[Xen-devel] [xen-4.5-testing baseline-only test] 67545: regressions - FAIL

This run is configured for baseline tests only. flight 67545 xen-4.5-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67545/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-amd 14

[Xen-devel] [PATCH net-next] xen-netback: create a debugfs node for hash information

It is useful to be able to see the hash configuration when running tests. This patch adds a debugfs node for that purpose. Signed-off-by: Paul Durrant Cc: Wei Liu --- drivers/net/xen-netback/common.h | 4 +++ drivers/net/xen-netback/hash.c | 68

Re: [Xen-devel] [PATCH v3 36/38] altp2m: Allow specifying external-only use-case

On 08/16/2016 06:17 PM, Sergej Proskurin wrote: From: Tamas K Lengyel Currently setting altp2mhvm=1 in the domain configuration allows access to the altp2m interface for both in-guest and external privileged tools. This poses a problem for use-cases where only

[Xen-devel] [PATCH 0/2] tools/libs: don't use alloca(3)

Wei Liu (2): libs/gnttab: do not use alloca(3) libs/foreignmemory: do not use alloca(3) tools/libs/foreignmemory/linux.c | 21 +++-- tools/libs/gnttab/linux.c| 19 ++- 2 files changed, 13 insertions(+), 27 deletions(-) -- 2.1.4

[Xen-devel] [PATCH 2/2] libs/foreignmemory: do not use alloca(3)

The semantics of alloca(3) is not very nice. If the stack overflows, program behaviour is undefined. Remove the use of alloca(3) and always use mmap. Signed-off-by: Wei Liu --- tools/libs/foreignmemory/linux.c | 21 +++-- 1 file changed, 7 insertions(+), 14

[Xen-devel] [PATCH 1/2] libs/gnttab: do not use alloca(3)

The semantics of alloca(3) is not very nice. If the stack overflows, program behaviour is undefined. Remove the use of alloca(3) and always use mmap. Signed-off-by: Wei Liu --- tools/libs/gnttab/linux.c | 19 ++- 1 file changed, 6 insertions(+), 13

Re: [Xen-devel] [PATCH] ns16550: mask transmit holding register empty interrupt when tx is stopped

>>> On 17.08.16 at 16:02, wrote: > From: Chris Patterson > > The uart generates an interrupt whenever the transmit holding register is > empty and UART_IER_ETHREI is set in UART_IER. Currently, Xen's ns16550 > driver does not currently mask this

Re: [Xen-devel] [PATCH] mini-os: fix coverity issues in printf.c

On Wed, Aug 17, 2016 at 04:25:44PM +0200, Juergen Gross wrote: > On 17/08/16 16:13, Wei Liu wrote: > > On Wed, Aug 17, 2016 at 03:39:59PM +0200, Juergen Gross wrote: > >> Fix two issues discovered by coverity. > > > > I would update the commit message to make it contain more information. > > > >

Re: [Xen-devel] [PATCH] mini-os: fix coverity issues in printf.c

On 17/08/16 16:13, Wei Liu wrote: > On Wed, Aug 17, 2016 at 03:39:59PM +0200, Juergen Gross wrote: >> Fix two issues discovered by coverity. > > I would update the commit message to make it contain more information. > > Fix two issues discovered by Coverity: > > 1. properl mark one switch case

Re: [Xen-devel] [PATCH] mini-os: fix coverity issues in printf.c

On Wed, Aug 17, 2016 at 03:39:59PM +0200, Juergen Gross wrote: > Fix two issues discovered by coverity. I would update the commit message to make it contain more information. Fix two issues discovered by Coverity: 1. properl mark one switch case as fall-through 2. unroll a loop that only

[Xen-devel] [PATCH] ns16550: mask transmit holding register empty interrupt when tx is stopped

From: Chris Patterson The uart generates an interrupt whenever the transmit holding register is empty and UART_IER_ETHREI is set in UART_IER. Currently, Xen's ns16550 driver does not currently mask this interrupt when transmit is stopped, unlike other platforms such as

Re: [Xen-devel] [MINIOS PATCH 2/4] Introduce asm_macros.h

On Wed, Aug 17, 2016 at 03:03:44PM +0100, Wei Liu wrote: > On Wed, Aug 17, 2016 at 03:01:07PM +0100, Andrew Cooper wrote: > > On 17/08/16 13:35, Wei Liu wrote: > > > diff --git a/include/asm_macros.h b/include/asm_macros.h > > > new file mode 100644 > > > index 000..15dd377 > > > --- /dev/null

Re: [Xen-devel] [MINIOS PATCH 2/4] Introduce asm_macros.h

On Wed, Aug 17, 2016 at 03:01:07PM +0100, Andrew Cooper wrote: > On 17/08/16 13:35, Wei Liu wrote: > > diff --git a/include/asm_macros.h b/include/asm_macros.h > > new file mode 100644 > > index 000..15dd377 > > --- /dev/null > > +++ b/include/asm_macros.h > > @@ -0,0 +1,36 @@ > > +/* > > + *

Re: [Xen-devel] [MINIOS PATCH 2/4] Introduce asm_macros.h

On 17/08/16 13:35, Wei Liu wrote: > diff --git a/include/asm_macros.h b/include/asm_macros.h > new file mode 100644 > index 000..15dd377 > --- /dev/null > +++ b/include/asm_macros.h > @@ -0,0 +1,36 @@ > +/* > + * Macros for assembly files. > + */ > + > +#ifndef _ASM_MACRO_H_ > +#define

Re: [Xen-devel] [Minios-devel] [MINIOS PATCH 3/4] x86: switch to use elfnote

On 17/08/16 14:35, Wei Liu wrote: > Use the newer ELF note interface. The generated ELF notes results in > equivalent configuration. > > Also need to modify linker script to provide a note section. > > Signed-off-by: Wei Liu Reviewed-by: Juergen Gross

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

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

Re: [Xen-devel] [MINIOS PATCH 2/4] Introduce asm_macros.h

On 17/08/16 14:40, Wei Liu wrote: > On Wed, Aug 17, 2016 at 02:56:00PM +0200, Samuel Thibault wrote: >> Hello, >> >> Wei Liu, on Wed 17 Aug 2016 13:35:12 +0100, wrote: >>> Ported from xtf.git. >> What is xtf.git? Does it use the same BSD licencing? >> To my knowledge this is coming from the linux

Re: [Xen-devel] [MINIOS PATCH 2/4] Introduce asm_macros.h

On Wed, Aug 17, 2016 at 02:40:09PM +0100, Wei Liu wrote: > On Wed, Aug 17, 2016 at 02:56:00PM +0200, Samuel Thibault wrote: > > Hello, > > > > Wei Liu, on Wed 17 Aug 2016 13:35:12 +0100, wrote: > > > Ported from xtf.git. > > > > What is xtf.git? Does it use the same BSD licencing? > > To my

[Xen-devel] Ping: [PATCH v2 2/6] x86/time: correctly honor late clearing of TSC related feature flags

Ping? >>> On 03.08.16 at 15:00, wrote: > As such clearing of flags may have an impact on the selected rendezvous > function, handle such in a central place. > > But don't allow such feature flags to be cleared during CPU hotplug: > Platform and local system times may have

Re: [Xen-devel] [MINIOS PATCH 2/4] Introduce asm_macros.h

On Wed, Aug 17, 2016 at 02:56:00PM +0200, Samuel Thibault wrote: > Hello, > > Wei Liu, on Wed 17 Aug 2016 13:35:12 +0100, wrote: > > Ported from xtf.git. > > What is xtf.git? Does it use the same BSD licencing? > To my knowledge this is coming from the linux kernel source. This:

[Xen-devel] Ping: Re: [PATCH] replace bogus -ENOSYS uses

>>> On 12.08.16 at 13:02, wrote: Ping: On 12.08.16 at 12:34, wrote: >> On 11/08/16 19:10, Andrew Cooper wrote: >>> On 09/08/16 11:40, Jan Beulich wrote: --- a/xen/arch/x86/cpu/mtrr/main.c +++ b/xen/arch/x86/cpu/mtrr/main.c @@

[Xen-devel] [PATCH] mini-os: fix coverity issues in printf.c

Fix two issues discovered by coverity. Signed-off-by: Juergen Gross --- lib/printf.c | 25 +++-- 1 file changed, 11 insertions(+), 14 deletions(-) diff --git a/lib/printf.c b/lib/printf.c index ad6a304..f9e9d68 100644 --- a/lib/printf.c +++ b/lib/printf.c

Re: [Xen-devel] [MINIOS PATCH 2/4] Introduce asm_macros.h

Hello, Wei Liu, on Wed 17 Aug 2016 13:35:12 +0100, wrote: > Ported from xtf.git. What is xtf.git? Does it use the same BSD licencing? To my knowledge this is coming from the linux kernel source. > Signed-off-by: Wei Liu > --- > include/asm_macros.h | 36

Re: [Xen-devel] [PATCH 9/9] x86/mtrr: use stdbool instead of int + define

>>> On 17.08.16 at 01:28, wrote: > --- a/xen/arch/x86/cpu/mtrr/generic.c > +++ b/xen/arch/x86/cpu/mtrr/generic.c > @@ -3,6 +3,7 @@ > #include > #include > #include > +#include Is this really needed, with xen/types.h already including it? > @@ -237,7 +238,7 @@ static

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

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

Re: [Xen-devel] [PATCH 8/9] x86/mtrr: drop unused func prototypes and struct

>>> On 17.08.16 at 01:28, wrote: > These weren't used so drop them. > > Signed-off-by: Doug Goldstein Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH 7/9] x86/mtrr: drop unused positive_have_wrcomb()

>>> On 17.08.16 at 01:28, wrote: > Unused function, gone. > > Signed-off-by: Doug Goldstein Acked-by: Jan Beulich But perhaps worth getting folded into the one dropping have_wrcomb() (the acks for both patches can be retained for the

Re: [Xen-devel] [PATCH 6/9] x86/mtrr: drop unused mtrr_ops struct

>>> On 17.08.16 at 01:28, wrote: > There are no users of the mtrr_ops struct or any of the callers on it so > drop those. > > Signed-off-by: Doug Goldstein Acked-by: Jan Beulich ___

Re: [Xen-devel] [PATCH 5/9] x86/mtrr: drop unused is_cpu() macro

>>> On 17.08.16 at 01:28, wrote: > --- a/xen/arch/x86/cpu/mtrr/generic.c > +++ b/xen/arch/x86/cpu/mtrr/generic.c > @@ -520,7 +520,7 @@ int mtrr_generic_validate_add_page(unsigned long base, > unsigned long size, unsig > > /* For Intel PPro stepping <= 7, must be 4 MiB

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

flight 100518 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100518/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-winxpsp3 17 guest-start/win.repeat fail REGR. vs. 100488 Regressions

Re: [Xen-devel] [PATCH 4/9] x86/mtrr: drop unnecessary use_intel() macro

>>> On 17.08.16 at 01:28, wrote: > The use_intel() macro always evaluates to true so don't bother using it. Ah, here we go. But there are indentation issues again here. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH 3/9] x86/mtrr: drop have_wrcomb() wrapper

>>> On 17.08.16 at 01:28, wrote: > The only call was always to the generic implementation. > > Signed-off-by: Doug Goldstein Acked-by: Jan Beulich ___ Xen-devel mailing list

Re: [Xen-devel] [MINIOS PATCH 4/4] x86: use unified linker script

On 17/08/16 13:35, Wei Liu wrote: > diff --git a/arch/x86/minios-x86.lds.S b/arch/x86/minios-x86.lds.S > new file mode 100644 > index 000..65650ab > --- /dev/null > +++ b/arch/x86/minios-x86.lds.S > @@ -0,0 +1,133 @@ > +#if defined(__x86_64__) > + > +OUTPUT_FORMAT("elf64-x86-64",

Re: [Xen-devel] [MINIOS PATCH 1/4] gitignore: ignore vim swap file

Wei Liu, on Wed 17 Aug 2016 13:35:11 +0100, wrote: > Signed-off-by: Wei Liu Reviewed-by: Samuel Thibault > --- > .gitignore | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/.gitignore b/.gitignore > index 1c655a0..f21cc46 100644 >

Re: [Xen-devel] [PATCH 2/9] x86/mtrr: drop mtrr_if indirection

>>> On 17.08.16 at 01:28, wrote: > There can only ever be one mtrr_if now and that is the generic > implementation This is only true when taking into consideration that cpu_has_mtrr is #define-d to 1 right now. I'm not sure that's actually a good assumption (especially when

Re: [Xen-devel] [PATCH v3 31/38] altp2m: Introduce altp2m_switch_vcpu_altp2m_by_id

On 17/08/16 13:37, Sergej Proskurin wrote: On 08/17/2016 12:05 PM, Jan Beulich wrote: On 17.08.16 at 00:17, wrote: xen/arch/arm/altp2m.c| 32 xen/arch/x86/mm/altp2m.c | 6 ++ xen/arch/x86/mm/p2m.c| 6 --

Re: [Xen-devel] [MINIOS PATCH 4/4] x86: use unified linker script

On Wed, Aug 17, 2016 at 01:35:14PM +0100, Wei Liu wrote: > There are only a few differences between i386 and x86-64 linker scripts. > Unify them into one. Re-indent the file at the same time. > > Construct a special rule in top-level directory to cope with the change. > Ideally the build system

Re: [Xen-devel] Xen virtual IOMMU high level design doc

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of > Lan, Tianyu > Sent: 17 August 2016 13:06 > To: Jan Beulich; Kevin Tian; Andrew Cooper; yang.zhang...@gmail.com; Jun > Nakajima; Stefano Stabellini > Cc: Anthony Perard; xuqu...@huawei.com; xen- >

Re: [Xen-devel] [PATCH v3 31/38] altp2m: Introduce altp2m_switch_vcpu_altp2m_by_id

Hi Jan, On 08/17/2016 12:05 PM, Jan Beulich wrote: On 17.08.16 at 00:17, wrote: >> xen/arch/arm/altp2m.c| 32 >> xen/arch/x86/mm/altp2m.c | 6 ++ >> xen/arch/x86/mm/p2m.c| 6 -- >>

[Xen-devel] [MINIOS PATCH 0/4] x86: Use ELF notes and unfied linker script

Wei Liu (4): gitignore: ignore vim swap file Introduce asm_macros.h x86: switch to use elfnote x86: use unified linker script .gitignore | 2 + Makefile | 6 +- arch/x86/Makefile | 1 + arch/x86/minios-x86.lds.S | 133

Re: [Xen-devel] [PATCH 1/9] x86/mtrr: prefix fns with mtrr and drop static

>>> On 17.08.16 at 01:28, wrote: > For the functions that make up the interface to the MTRR code, drop the > static keyword and prefix them all with mtrr for improved clarity when > they're called outside this file. This also required adjusting or > providing function

[Xen-devel] [MINIOS PATCH 2/4] Introduce asm_macros.h

Ported from xtf.git. Signed-off-by: Wei Liu --- include/asm_macros.h | 36 include/x86/asm_macros.h | 28 2 files changed, 64 insertions(+) create mode 100644 include/asm_macros.h create mode 100644

  1   2   >