Re: [Xen-devel] [PATCH] VT-d: Chop down the DMAR_OPERATION_TIMEOUT to a low number of milliseconds.

On March 15, 2016 12:38pm, Tian, Kevin wrote: > > From: Xu, Quan > > Sent: Monday, March 14, 2016 3:16 PM > > > > We confirmed with VT-d hardware team that 1ms is large enough for > > IOMMU internal flush. So We can change the DMAR_OPERATION_TIMEOUT > from > > 1000 ms to 1

Re: [Xen-devel] [PATCH v2] vmx: Restore debug registers when injecting #DB traps

> From: Ross Lagerwall [mailto:ross.lagerw...@citrix.com] > Sent: Saturday, March 12, 2016 12:24 AM > > Commit a929bee0e652 ("x86/vmx: Fix injection of #DB traps following > XSA-156") prevents an infinite loop in certain #DB traps. However, it > changed the behavior to not call

Re: [Xen-devel] [PATCH] VT-d: Chop down the DMAR_OPERATION_TIMEOUT to a low number of milliseconds.

> From: Xu, Quan > Sent: Monday, March 14, 2016 3:16 PM > > We confirmed with VT-d hardware team that 1ms is large enough for IOMMU > internal flush. So We can change the DMAR_OPERATION_TIMEOUT from 1000 ms > to 1 ms. > > Signed-off-by: Quan Xu > Acked-by: Kevin Tian

[Xen-devel] [xen-4.3-testing test] 86202: regressions - trouble: blocked/broken/fail/pass

flight 86202 xen-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/86202/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 3 host-install(3) broken REGR. vs. 83004

[Xen-devel] Sharing memory between two virtual machine on XEN Hypervisor

*Dear All* *I have installed two virtual machine on XEN hyper-visor. Now I want two write a program which share the memory between two virtual machine. Could any help me please.* *Thanks and Regards,* Zakira Inayat Ph.D Scholar in University of Malaya, Malaysia

[Xen-devel] [linux-4.1 test] 86197: regressions - trouble: blocked/broken/fail/pass

flight 86197 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/86197/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399 build-i386-rumpuserxen

Re: [Xen-devel] [PATCH 1/2] x86/mm/pat: Change pat_disable() to emulate PAT table

On Tue, 2016-03-15 at 01:29 +0100, Luis R. Rodriguez wrote: > I like this approach more as it stuff more PAT setup on its own type > of calls, but: > > On Sat, Mar 12, 2016 at 12:55:44PM +0100, Borislav Petkov wrote: > > diff --git a/arch/x86/kernel/cpu/mtrr/main.c > >

[Xen-devel] [PATCH v4 2/3] tools: change checkpointed_stream's type from int to xc_migration_stream_t

checkpointed_stream is also renamed to stream_type Signed-off-by: Wen Congyang Acked-by: Wei Liu --- v2->v3: Rename checkpointed_stream to stream_type tools/libxc/include/xenguest.h | 8 tools/libxc/xc_nomigrate.c | 4 ++--

[Xen-devel] [PATCH v4 3/3] libxl: rename checkpointed_stream to stream_type

Signed-off-by: Wen Congyang --- v3->v4: Remove the new macro, and updte the macro LIBXL_HAVE_CHECKPOINTED_STREAM tools/libxl/libxl.c | 4 ++-- tools/libxl/libxl.h | 4 +++- tools/libxl/libxl_create.c | 4 ++-- tools/libxl/libxl_dom_save.c

[Xen-devel] [PATCH v4 1/3] libxc: move migration_stream's definition to xenguest.h

xc_domain_save() and xc_domain_restore's parameter will use this type, so it should be public. Signed-off-by: Wen Congyang Acked-by: Wei Liu --- v2->v3: Rename MIG_STREAM_* to XC_MIG_STREAM_* tools/libxc/include/xenguest.h | 7 ++-

Re: [Xen-devel] [PATCH] tools: Restrict configuration of qemu processes

Opps, forgot to cc the tools maintainers, sorry. I can resend if needed. Regards, Jim On 03/14/2016 07:08 PM, Jim Fehlig wrote: > Commit 6ef823fd added '-nodefaults' to the qemu args created by > libxl, which is a good step in restricting qemu's default > configuration. This change takes another

[Xen-devel] [PATCH] tools: Restrict configuration of qemu processes

Commit 6ef823fd added '-nodefaults' to the qemu args created by libxl, which is a good step in restricting qemu's default configuration. This change takes another step by adding -no-user-config, which ignores any user-provided config files in sysconfdir. Together, -nodefaults and -no-user-config

[Xen-devel] [PATCH] docs: update FLASK cmd line instructions

The command line instructions for FLASK include a note on how to compile Xen with FLASK but the note was out of date after the change to Kconfig. Signed-off-by: Doug Goldstein --- CC: Ian Jackson CC: Jan Beulich CC: Keir Fraser

[Xen-devel] can xenrt be used to test libxenlight/libvirt APIs directly?

Hi all: I'm not sure but doubt that xenRT is used to just test xenserver/xapi, it's not appropriate for testing libxenlight, am I right? Although it uses libvirt to do guest lifecycle jobs, see file " ./exec/xenrt/lib/libvirt/guest.py", but it seems that these functions are all used by

Re: [Xen-devel] [PATCH 1/2] x86/mm/pat: Change pat_disable() to emulate PAT table

I like this approach more as it stuff more PAT setup on its own type of calls, but: On Sat, Mar 12, 2016 at 12:55:44PM +0100, Borislav Petkov wrote: > diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c > index 10f8d4796240..5c442b4bd52a 100644 > ---

Re: [Xen-devel] [RFC PATCH v1] Splitting off stubdom to a different tree

Hello, Wei Liu, on Thu 10 Mar 2016 16:46:39 +, wrote: > 1. There are some open questions -- see individual commits. Not sure I have seen them all, but here are some bits of answers: - Not sure what the version number of stubdom.git should be. Indeed. I don't really have an opinion on this,

Re: [Xen-devel] [PATCH 2/2] x86/mtrr: Refactor PAT initialization code

On Fri, Mar 11, 2016 at 06:16:36PM -0700, Toshi Kani wrote: > On Fri, 2016-03-11 at 15:34 -0800, Luis R. Rodriguez wrote: > > On Fri, Mar 11, 2016 at 3:56 PM, Toshi Kani wrote: > > > On Fri, 2016-03-11 at 23:17 +0100, Luis R. Rodriguez wrote: > > > > On Fri, Mar 11, 2016 at

[Xen-devel] [PATCH v9]xen: sched: convert RTDS from time to event driven model

Budget replenishment and enforcement are separated by adding a replenishment timer, which fires at the next most imminent release time of all runnable vcpus. A replenishment queue has been added to keep track of all vcpus that are runnable. The following functions have major changes to manage

[Xen-devel] [linux-linus test] 86187: regressions - FAIL

flight 86187 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/86187/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254

[Xen-devel] [ovmf test] 86194: regressions - FAIL

flight 86194 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/86194/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543

Re: [Xen-devel] [PATCH 0/5] Allow tmem to be disabled via Kconfig

On Mon, Mar 14, 2016 at 03:29:20PM -0500, Doug Goldstein wrote: > First swag at allowing tmem to be disabled via Kconfig. I've only build > tested this first version because I expect a bunch of feedback that will > necessitate changes and then v2 will hopefully be worth testing. The > first 4

[Xen-devel] [PATCH 3/5] tmem: make tmem_freeable_pages() check tmem status

Most callers of tmem_freeable_pages() checked to see if tmem was enabled before calling tmem_freeable_pages() but not all of them did. This seemed like an oversight and to avoid similar situations like that, stick the check of tmem into tmem_freeable_pages(). Signed-off-by: Doug Goldstein

[Xen-devel] [PATCH 1/5] tmem: add tmem_disable() function

Instead of manipulating the opt_tmem variable directly utilize a wrapper function. Signed-off-by: Doug Goldstein --- CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper CC: Konrad Rzeszutek Wilk

[Xen-devel] [PATCH 2/5] tmem: drop direct usage of opt_tmem

Don't use the opt_tmem variable to check if tmem is enabled, instead use the tmem_enabled() helper function everywhere. Signed-off-by: Doug Goldstein --- CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper CC: Konrad

[Xen-devel] [PATCH 4/5] tmem: don't assume stdbool.h is included

tmem_xen.h assumes that all users will have already included stdbool.h which might not always be true. Signed-off-by: Doug Goldstein --- CC: Konrad Rzeszutek Wilk --- xen/include/xen/tmem_xen.h | 1 + 1 file changed, 1 insertion(+) diff --git

[Xen-devel] [PATCH 5/5] tmem: allow tmem to be disabled with Kconfig

Wrap the various tmem functions with the Kconfig generated CONFIG_TMEM option allowing users to build Xen without tmem support. Signed-off-by: Doug Goldstein --- CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper

[Xen-devel] [PATCH 0/5] Allow tmem to be disabled via Kconfig

First swag at allowing tmem to be disabled via Kconfig. I've only build tested this first version because I expect a bunch of feedback that will necessitate changes and then v2 will hopefully be worth testing. The first 4 patches can go in regardless of the final patch and are really just

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

flight 86241 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/86241/ 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 12

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Mon, Mar 14, 2016 at 11:10:16AM -0700, Andy Lutomirski wrote: > A couple of the wrmsr users actually care about performance. These > are the ones involved in context switching and, to a lesser extent, in > switching in and out of guest mode. Right, this very much includes a number of perf

Re: [Xen-devel] [RFC] tools: don't use qemu default config

On 03/11/2016 03:28 PM, Konrad Rzeszutek Wilk wrote: > On Fri, Mar 11, 2016 at 03:08:30PM -0700, Jim Fehlig wrote: >> I recently changed SUSE's Xen package to use the distro qemu instead of >> building >> qemu-xen. This got some other eyes looking at Xen's use of qemu and it was >> noticed that

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Mon, Mar 14, 2016 at 11:40 AM, Linus Torvalds wrote: > On Mon, Mar 14, 2016 at 11:24 AM, Andy Lutomirski wrote: >> >> The code in my queue is, literally: >> >> bool ex_handler_rdmsr_unsafe(const struct exception_table_entry *fixup, >>

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Mon, Mar 14, 2016 at 11:24 AM, Andy Lutomirski wrote: > > The code in my queue is, literally: > > bool ex_handler_rdmsr_unsafe(const struct exception_table_entry *fixup, > struct pt_regs *regs, int trapnr) > { > WARN_ONCE(1, "unchecked MSR access

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Mon, Mar 14, 2016 at 11:15 AM, Linus Torvalds wrote: > On Mon, Mar 14, 2016 at 11:10 AM, Andy Lutomirski wrote: >> >> A couple of the wrmsr users actually care about performance. These >> are the ones involved in context switching and, to a

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Mon, Mar 14, 2016 at 11:04 AM, Linus Torvalds wrote: > On Mon, Mar 14, 2016 at 10:17 AM, Andy Lutomirski wrote: >> >> So yes, let's please warn. I'm okay with removing the panic_on_oops >> thing though. (But if anyone suggests that we

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Mon, Mar 14, 2016 at 11:10 AM, Andy Lutomirski wrote: > > A couple of the wrmsr users actually care about performance. These > are the ones involved in context switching and, to a lesser extent, in > switching in and out of guest mode. .. ok, see the crossed emails. I'd

[Xen-devel] [linux-mingo-tip-master test] 86186: regressions - FAIL

flight 86186 linux-mingo-tip-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/86186/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684

Re: [Xen-devel] [PATCH] xen: Restore p2m_access_t enum order to allow bitmask semantics

On Fri, Mar 11, 2016 at 8:53 AM, Malcolm Crossley wrote: > On 10/03/16 20:48, Tamas K Lengyel wrote: >> >> >> On Wed, Mar 9, 2016 at 5:30 PM, George Dunlap > > wrote: >> >> On 08/03/16 15:30, Malcolm

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Mon, Mar 14, 2016 at 11:04 AM, Linus Torvalds wrote: > > None of this insane complicated crap that buys us exactly *nothing*, > and depends on fancy new exception handling support etc etc. Actually, the one _new_ thing we could do is to instead of removing the

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Mon, Mar 14, 2016 at 10:17 AM, Andy Lutomirski wrote: > > So yes, let's please warn. I'm okay with removing the panic_on_oops > thing though. (But if anyone suggests that we should stop OOPSing on > bad kernel page faults, I *will* fight back.) Bad kernel page faults

[Xen-devel] [PATCH v4 10/14] hvmloader: Load SeaBIOS from hvm_start_info modules

... and do not include the SeaBIOS ROM into hvmloader anymore. This also fix the dependency on roms.inc, hvmloader.o does not include it. Signed-off-by: Anthony PERARD --- Change in V4: - check that seabios_config.bios_address have a probably good value instead of

[Xen-devel] [PATCH v4 12/14] hvmloader: Specific bios_load function required

All BIOS but ROMBIOS needs to be loaded via modules. ROMBIOS is handled as a special case. Signed-off-by: Anthony PERARD Acked-by: Jan Beulich --- No change in V4. Change in V3: - reprint Main BIOS in bios map with now available information from

[Xen-devel] [PATCH v4 14/14] configure: do not depend on SEABIOS_PATH or OVMF_PATH ...

... to compile SeaBIOS and OVMF. Only depends on CONFIG_*. If --with-system-* configure option is used, then set *_CONFIG=n to not compile SEABIOS and OVMF. Signed-off-by: Anthony PERARD --- Change in V4: - change subject prefix Please, run ./autogen.sh on this

[Xen-devel] [PATCH v4 11/14] hvmloader: Load OVMF from modules

... and do not include the OVMF ROM into hvmloader anymore. Signed-off-by: Anthony PERARD --- Change in V4: - check if source and dest of ovmf binary does not overlaps Change in V3: - change makefile to not include ovmf rom into roms.inc. - update the struct

[Xen-devel] [PATCH v4 13/14] hvmloader: Always build-in SeaBIOS and OVMF loader

Signed-off-by: Anthony PERARD Acked-by: Jan Beulich --- tools/firmware/hvmloader/Makefile| 11 +-- tools/firmware/hvmloader/hvmloader.c | 4 2 files changed, 1 insertion(+), 14 deletions(-) diff --git

[Xen-devel] [PATCH v4 04/14] firmware/makefile: install BIOS blob ...

... into the firmware directory, along with hvmloader. Signed-off-by: Anthony PERARD --- Change in V4: - remove install of acpi dsdt table Change in V3: - do not check if ROMs file exist before installing, they should exist - change rules for dsdt_anycpu_qemu_xen.c in

[Xen-devel] [PATCH v4 05/14] libxl: Load guest BIOS from file

The path to the BIOS blob can be override by the xl's bios_override option, or provided by u.hvm.bios_firmware in the domain_build_info struct by other libxl user. Signed-off-by: Anthony PERARD --- Change in V4: - updating man page to have bios_override described. -

Re: [Xen-devel] [PATCHv1] hvmloader: add high memory e820 region if needed

On 14/03/16 17:53, David Vrabel wrote: > If the MMIO hole is large and hvmloader needs to relocate memory to > immediately above the 4 GiB boundary, the e820 presented to the guest > will not have a RAM region above 4 GiB. > > e.g., a guest with 3 GiB of memory and a 2 GiB MMIO hole will only see

[Xen-devel] [PATCH v4 00/14] Load BIOS via toolstack instead of been embedded in hvmloader.

Hi all, Few changes in V4: I leave the ACPI alone and only load the BIOS via libxl now. Detail of changes in each patches. I've look at loading the BIOS via the toolstack instead of having them embedded in the hvmloader binary. After this patch series, hvmloader compilation would be

[Xen-devel] [PATCH v4 06/14] xen: Move the hvm_start_info C representation from libxc to public/xen.h

Instead of having several representation of hvm_start_info in C, define it in public/xen.h so both libxc and hvmloader can use it. Signed-off-by: Anthony PERARD --- New in V4. --- tools/libxc/include/xc_dom.h | 31 ---

[Xen-devel] [PATCH v4 02/14] libxc: Prepare a start info structure for hvmloader

... and load BIOS into guest memory. This adds a new firmware module, bios_module. It is loaded in the guest memory and final location is provided to hvmloader via the hvm_start_info struct. This patch create the hvm_start_info struct for HVM guest that have a device model, so this is now common

[Xen-devel] [PATCH v4 07/14] hvmloader: Grab the hvm_start_info pointer

Signed-off-by: Anthony PERARD --- Change in V4: - remove struct hvm_info_start redefinition, as it's moved to public/xen.h in a previous patch. Change in V3: - remove cmdline parser - load hvm_start_info pointer earlier, before calling main(). - Add struct

[Xen-devel] [PATCH v4 08/14] hvmloader: Locate the BIOS blob

The BIOS can be found an entry called "bios" of the modlist of the hvm_start_info struct. The found BIOS blob is not loaded by this patch, but only passed as argument to bios_load() function. It is going to be used by the next few patches. Signed-off-by: Anthony PERARD

[Xen-devel] [PATCH v4 01/14] libxc: Rework extra module initialisation

This patch use xc_dom_alloc_segment() to allocate the memory space for the ACPI modules and the SMBIOS modules. This is to replace the arbitrary placement of 1MB after the hvmloader image. In later patches, while trying to load a firmware such as OVMF, the later could easily be loaded past the

[Xen-devel] [PATCH v4 03/14] configure: #define SEABIOS_PATH and OVMF_PATH

Those paths are to be used by libxl, in order to load the firmware in memory. If a system path is not define via --with-system-seabios or --with-system-ovmf, then this default to the Xen firmware directory. Signed-off-by: Anthony PERARD --- Please, run ./autogen.sh on

[Xen-devel] [PATCH v4 09/14] hvmloader: Check modules whereabouts in perform_tests

As perform_tests() is going to clear memory past 4MB, we check that the memory can be use or we skip the tests. Signed-off-by: Anthony PERARD --- Changes in v4: - move the check into the perform_test() function. - skip tests instead of using BUG. New in V3 ---

[Xen-devel] [PATCHv1] hvmloader: add high memory e820 region if needed

If the MMIO hole is large and hvmloader needs to relocate memory to immediately above the 4 GiB boundary, the e820 presented to the guest will not have a RAM region above 4 GiB. e.g., a guest with 3 GiB of memory and a 2 GiB MMIO hole will only see 2 GiB. The required e820 memory region above 4

Re: [Xen-devel] [PATCH v8]xen: sched: convert RTDS from time to event driven model

On Mon, Mar 14, 2016 at 12:35 PM, Dario Faggioli wrote: > On Mon, 2016-03-14 at 12:03 -0400, Meng Xu wrote: >> On Mon, Mar 14, 2016 at 11:38 AM, Meng Xu >> wrote: >> > >> > I'm ok that we keep using spin_lock_irqsave() for now. But maybe >> >

Re: [Xen-devel] [PATCH v8]xen: sched: convert RTDS from time to event driven model

> >> So IMHO, the replenishment handler will be called in interrupt >> handler >> *and* with interrupt enabled. >> The only difference between lock_irq() and lock_irqsave() is that >> lock_irq() can only be called with interrupt enabled. (lock_irq will >> check if the interrupt is enabled before

Re: [Xen-devel] [PATCH] xen: arm: zero EL2 pagetable pages before use

Hi Julien, On 03/12/2016 10:03 AM, Julien Grall wrote: > Hi, > > On 11/03/2016 20:24, Andrew Cooper wrote: >> On 11/03/16 13:13, Jan Beulich wrote: >> On 11.03.16 at 13:56, wrote: On 11/03/16 11:29, Jan Beulich wrote: On 10.03.16 at 23:00,

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Mon, Mar 14, 2016 at 10:11 AM, Linus Torvalds wrote: > > On Mar 14, 2016 10:05 AM, "Andy Lutomirski" wrote: >> >> We could probably remove that check and let custom fixups run early. >> I don't see any compelling reason to keep them

Re: [Xen-devel] [PATCH] libxl: use LIBXL__LOG in libxl_ctx_alloc

Wei Liu writes ("[PATCH] libxl: use LIBXL__LOG in libxl_ctx_alloc"): > Coverity points out that using LOG macro dereferences gc which is NULL > at that point. Use LIBXL__LOG instead. > > CID: 1343291 > > Signed-off-by: Wei Liu Acked-by: Ian Jackson

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Mar 14, 2016 10:05 AM, "Andy Lutomirski" wrote: > > We could probably remove that check and let custom fixups run early. > I don't see any compelling reason to keep them disabled. That should > probably be a separate change, though. Or we could just use the existing

Re: [Xen-devel] [PATCH v4 1/5] x86/paravirt: Add _safe to the read_msr and write_msr PV hooks

On Mon, Mar 14, 2016 at 4:57 AM, Borislav Petkov wrote: > On Sat, Mar 12, 2016 at 10:08:48AM -0800, Andy Lutomirski wrote: >> These hooks match the _safe variants, so name them accordingly. >> This will make room for unsafe PV hooks. >> >> Signed-off-by: Andy Lutomirski

Re: [Xen-devel] [PATCH v2 3/3] xl: new "loglvl" command

Jan Beulich writes ("Re: [PATCH v2 3/3] xl: new "loglvl" command"): > They could become more fine grained (for example, Linux has a > few more than we have now). And the string/number correlation > is an implementation detail anyway. Could we solve that problem by multiplying the numbers by 10 ?

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Mon, Mar 14, 2016 at 5:02 AM, Borislav Petkov wrote: > On Sat, Mar 12, 2016 at 10:08:49AM -0800, Andy Lutomirski wrote: >> This demotes an OOPS and likely panic due to a failed non-"safe" MSR >> access to a WARN_ONCE and, for RDMSR, a return value of zero. If >> panic_on_oops

Re: [Xen-devel] [PATCH v3 3/5] x86/paravirt: Add paravirt_{read, write}_msr

On Mon, Mar 14, 2016 at 9:58 AM, Linus Torvalds wrote: > > On Mar 14, 2016 9:53 AM, "Andy Lutomirski" wrote: >> >> Can you clarify? KVM uses the native version, and the native version >> only oopses with this series applied if panic_on_oops is

Re: [Xen-devel] [PATCH v2 3/3] xl: new "loglvl" command

>>> On 14.03.16 at 17:01, wrote: > On Mon, Mar 14, 2016 at 09:49:11AM -0600, Jan Beulich wrote: >> >>> On 14.03.16 at 16:36, wrote: >> > On Mon, Mar 14, 2016 at 09:23:35AM -0600, Jan Beulich wrote: >> >> >>> On 08.03.16 at 17:20,

Re: [Xen-devel] [PATCH v3 3/5] x86/paravirt: Add paravirt_{read, write}_msr

On Mar 14, 2016 9:53 AM, "Andy Lutomirski" wrote: > > Can you clarify? KVM uses the native version, and the native version > only oopses with this series applied if panic_on_oops is set. Can we please remove that idiocy? There is no reason to panic whatsoever. Seriously.

Re: [Xen-devel] [PATCH v3 3/5] x86/paravirt: Add paravirt_{read, write}_msr

On Mar 14, 2016 7:03 AM, "Paolo Bonzini" wrote: > > > > On 11/03/2016 20:06, Andy Lutomirski wrote: > > This adds paravirt hooks for unsafe MSR access. On native, they > > call native_{read,write}_msr. On Xen, they use > > xen_{read,write}_msr_safe. > > > > Nothing uses

Re: [Xen-devel] [PATCH v8]xen: sched: convert RTDS from time to event driven model

On Mon, 2016-03-14 at 12:03 -0400, Meng Xu wrote: > On Mon, Mar 14, 2016 at 11:38 AM, Meng Xu > wrote: > >  > > I'm ok that we keep using spin_lock_irqsave() for now. But maybe > > later, it will be a better idea to explore if spin_lock_irq() can > > replace all

Re: [Xen-devel] [PATCH v8]xen: sched: convert RTDS from time to event driven model

On Mon, 2016-03-14 at 11:38 -0400, Meng Xu wrote: > Hi Dario, > Hi, > On Mon, Mar 14, 2016 at 7:58 AM, Dario Faggioli > wrote: > > I recommend looking at what happens inside init_timer(), i.e., > > where a > > pointer to this function is stashed. Then, still in > >

[Xen-devel] [PATCH] libxl: use LIBXL__LOG in libxl_ctx_alloc

Coverity points out that using LOG macro dereferences gc which is NULL at that point. Use LIBXL__LOG instead. CID: 1343291 Signed-off-by: Wei Liu --- Cc: Ian Jackson --- tools/libxl/libxl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[Xen-devel] [PATCH v2] xen/arm64: Fix incorrect memory region size in TCR_EL2

The maximum and minimum values for TxSZ depend on level of translation as per AArch64 Virtual Memory System Architecture. According to ARM specification DDI0487A_h (sec D4.2.2, page 1752), the minimum TxSZ value is 16. If TxSZ is programmed to a value smaller than 16 then it is IMPLEMENTATION

Re: [Xen-devel] [PATCH] x86: partially revert use of 2M mappings for hypervisor image

On 14/03/16 15:41, Jan Beulich wrote: On 14.03.16 at 16:23, wrote: >> On 14/03/16 15:12, Jan Beulich wrote: >>> --- a/xen/arch/x86/setup.c >>> +++ b/xen/arch/x86/setup.c >>> @@ -497,6 +497,17 @@ static void __init kexec_reserve_area(st >>> #endif >>> } >>> >>>

Re: [Xen-devel] [PATCH v2 3/3] xl: new "loglvl" command

On Mon, Mar 14, 2016 at 09:49:11AM -0600, Jan Beulich wrote: > >>> On 14.03.16 at 16:36, wrote: > > On Mon, Mar 14, 2016 at 09:23:35AM -0600, Jan Beulich wrote: > >> >>> On 08.03.16 at 17:20, wrote: > >> > On Fri, Mar 04, 2016 at 09:48:16AM -0700, Jan

Re: [Xen-devel] [PATCH v8]xen: sched: convert RTDS from time to event driven model

On Mon, Mar 14, 2016 at 11:38 AM, Meng Xu wrote: > Hi Dario, > > On Mon, Mar 14, 2016 at 7:58 AM, Dario Faggioli > wrote: >> On Fri, 2016-03-11 at 23:54 -0500, Meng Xu wrote: >>> >>> > @@ -1150,6 +1300,101 @@ rt_dom_cntl( >>> > return rc; >>>

Re: [Xen-devel] [PATCH v2 3/3] xl: new "loglvl" command

>>> On 14.03.16 at 16:36, wrote: > On Mon, Mar 14, 2016 at 09:23:35AM -0600, Jan Beulich wrote: >> >>> On 08.03.16 at 17:20, wrote: >> > On Fri, Mar 04, 2016 at 09:48:16AM -0700, Jan Beulich wrote: >> >> --- a/tools/libxl/xl_cmdimpl.c >> >> +++

Re: [Xen-devel] [PATCH v8]xen: sched: convert RTDS from time to event driven model

Hi Dario, On Mon, Mar 14, 2016 at 7:58 AM, Dario Faggioli wrote: > On Fri, 2016-03-11 at 23:54 -0500, Meng Xu wrote: >> >> > @@ -1150,6 +1300,101 @@ rt_dom_cntl( >> > return rc; >> > } >> > >> > +/* >> > + * The replenishment timer handler picks vcpus >> > + *

Re: [Xen-devel] [PATCH] x86: partially revert use of 2M mappings for hypervisor image

>>> On 14.03.16 at 16:23, wrote: > On 14/03/16 15:12, Jan Beulich wrote: >> --- a/xen/arch/x86/setup.c >> +++ b/xen/arch/x86/setup.c >> @@ -497,6 +497,17 @@ static void __init kexec_reserve_area(st >> #endif >> } >> >> +static inline bool_t using_2M_mapping(void) >>

Re: [Xen-devel] [PATCH v2 3/3] xl: new "loglvl" command

On Mon, Mar 14, 2016 at 09:23:35AM -0600, Jan Beulich wrote: > >>> On 08.03.16 at 17:20, wrote: > > On Fri, Mar 04, 2016 at 09:48:16AM -0700, Jan Beulich wrote: > >> This is pretty simplistic for now, but I'd rather have someone better > >> friends with the tools improve it

Re: [Xen-devel] [PATCH] x86: partially revert use of 2M mappings for hypervisor image

On 14/03/16 15:12, Jan Beulich wrote: > As explained by Andrew in > http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg01380.html > that change makes the uncompressed xen.gz image too large for certain > boot environments. As a result this change makes some of the effects of > commits

Re: [Xen-devel] [PATCH] x86: move both exception tables into .rodata

On 14/03/16 15:15, Jan Beulich wrote: > While they are being written during early boot (when sorting them), > that writing takes place before we actually start fiddling with page > table permissions, so these tables can benefit from getting write > protected just like ordinary r/o data does (for

Re: [Xen-devel] [PATCH v2 3/3] xl: new "loglvl" command

>>> On 08.03.16 at 17:20, wrote: > On Fri, Mar 04, 2016 at 09:48:16AM -0700, Jan Beulich wrote: >> This is pretty simplistic for now, but I'd rather have someone better >> friends with the tools improve it (if desired). >> >> Signed-off-by: Jan Beulich >>

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

flight 86218 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/86218/ 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 12

[Xen-devel] [PATCH] x86: move both exception tables into .rodata

While they are being written during early boot (when sorting them), that writing takes place before we actually start fiddling with page table permissions, so these tables can benefit from getting write protected just like ordinary r/o data does (for now only when using 2M mappings).

[Xen-devel] [PATCH] x86: partially revert use of 2M mappings for hypervisor image

As explained by Andrew in http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg01380.html that change makes the uncompressed xen.gz image too large for certain boot environments. As a result this change makes some of the effects of commits cf393624ee ("x86: use 2M superpages for

[Xen-devel] [xen-unstable test] 86183: tolerable FAIL

flight 86183 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/86183/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-freebsd10-i386 6 xen-boot fail in 86132 pass in 86183 test-armhf-armhf-xl-rtds 11

Re: [Xen-devel] [PATCH] xen/arm64: Fix incorrect memory region size in TCR2_EL2

On 14/03/16 14:37, Shanker Donthineni wrote: HI Jullen, Hi Shanker, On 03/12/2016 07:13 AM, Julien Grall wrote: Hi Shanker, On 11/03/2016 04:28, Shanker Donthineni wrote: The maximum and minimum values for T0SZ depend on level of translation as per AArch64 Virtual Memory System

Re: [Xen-devel] [PATCH] xen/arm64: Fix incorrect memory region size in TCR2_EL2

HI Jullen, On 03/12/2016 07:13 AM, Julien Grall wrote: > Hi Shanker, > > On 11/03/2016 04:28, Shanker Donthineni wrote: >> The maximum and minimum values for T0SZ depend on level of >> translation as per AArch64 Virtual Memory System Architecture. >> The current code sets T0SZ to zero in TCR2_EL2

Re: [Xen-devel] [PATCH v4 0/5] [PATCH v3 0/5] Improve non-"safe" MSR access failure handling

On 03/12/2016 01:08 PM, Andy Lutomirski wrote: Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently turns all rdmsr and wrmsr operations into the safe variants without any checks that the operations actually succeed. With CONFIG_PARAVIRT=n, unchecked MSR failures OOPS and

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

Hi Konrad, On Mon, Mar 14, 2016 at 7:42 PM, Konrad Rzeszutek Wilk wrote: >> After changing the console name to hvc0 the only thing which I noticed >> differently is >> that after the last line where Xen frees some init memory, I am able to see >> the linux >> kernel

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

> After changing the console name to hvc0 the only thing which I noticed > differently is > that after the last line where Xen frees some init memory, I am able to see > the linux > kernel decompression message - > > "(XEN) DOM0: Uncompressing Linux... done, booting the kernel. > > But after

Re: [Xen-devel] [PATCH 1/3] xenalyze: handle DOM0 operaions events

On Mon, 2016-03-14 at 10:06 -0400, Konrad Rzeszutek Wilk wrote: > On Sat, Mar 12, 2016 at 12:33:57PM +0100, Dario Faggioli wrote: > > > > (i.e., domain creation and destruction) so the > > trace will show properly decoded info, rather > > than just a bunch of hex codes. > Weirdly you also lost

Re: [Xen-devel] [PATCH 1/3] xenalyze: handle DOM0 operaions events

On Sat, Mar 12, 2016 at 12:33:57PM +0100, Dario Faggioli wrote: > (i.e., domain creation and destruction) so the > trace will show properly decoded info, rather > than just a bunch of hex codes. Weirdly you also lost your SoB. > --- > Cc: George Dunlap > Cc: Ian

Re: [Xen-devel] [PATCH 2/2] xsm: move FLASK_AVC_STATS to Kconfig

On 3/8/16 12:01 PM, Daniel De Graaf wrote: > On 03/08/2016 11:51 AM, Jan Beulich wrote: > On 08.03.16 at 17:22, wrote: >>> On 03/08/2016 04:46 AM, Jan Beulich wrote: >>> On 07.03.16 at 19:42, wrote: > Have Kconfig set CONFIG_FLASK_AVC_STATS

Re: [Xen-devel] [PATCH v3 3/5] x86/paravirt: Add paravirt_{read, write}_msr

On 11/03/2016 20:06, Andy Lutomirski wrote: > This adds paravirt hooks for unsafe MSR access. On native, they > call native_{read,write}_msr. On Xen, they use > xen_{read,write}_msr_safe. > > Nothing uses them yet for ease of bisection. The next patch will > use them in rdmsrl, wrmsrl, etc.

Re: [Xen-devel] [PATCH v8]xen: sched: convert RTDS from time to event driven model

On Mon, Mar 14, 2016 at 7:48 AM, Dario Faggioli wrote: > On Sun, 2016-03-13 at 11:43 -0400, Meng Xu wrote: >> On Sat, Mar 12, 2016 at 5:21 PM, Chen, Tianyang > > wrote: >> > On 03/11/2016 11:54 PM, Meng Xu wrote: >> > > One more thing we should

Re: [Xen-devel] [patch 1/4] hotplug: Prevent alloc/free of irq descriptors during cpu up/down

On 03/12/2016 04:19 AM, Thomas Gleixner wrote: Boris, On Tue, 14 Jul 2015, Boris Ostrovsky wrote: On 07/14/2015 04:15 PM, Thomas Gleixner wrote: The issue here is that all architectures need that protection and just Xen does irq allocations in cpu_up. So moving that protection into

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Sat, Mar 12, 2016 at 10:08:49AM -0800, Andy Lutomirski wrote: > This demotes an OOPS and likely panic due to a failed non-"safe" MSR > access to a WARN_ONCE and, for RDMSR, a return value of zero. If > panic_on_oops is set, then failed unsafe MSR accesses will still > oops and panic. > > To

Re: [Xen-devel] [PATCH v4 1/5] x86/paravirt: Add _safe to the read_msr and write_msr PV hooks

On Sat, Mar 12, 2016 at 10:08:48AM -0800, Andy Lutomirski wrote: > These hooks match the _safe variants, so name them accordingly. > This will make room for unsafe PV hooks. > > Signed-off-by: Andy Lutomirski > --- > arch/x86/include/asm/paravirt.h | 33

  1   2   >