Re: [Xen-devel] [PATCH] xen: arm: perfc: count individual SGIs and PPIs

On Mon, 2015-11-09 at 07:11 -0700, Jan Beulich wrote: > > > > On 09.11.15 at 15:01, wrote: > > SPIs are too numerous and not indivcidually as interesting. > > > > Make the exists #IPIS counter x86 specific. > > I'd recommend not to - even if ARM doesn't want to use it,

Re: [Xen-devel] [PATCH] xen: arm: perfc: count individual SGIs and PPIs

>>> On 09.11.15 at 15:24, wrote: > On 09/11/15 14:20, Ian Campbell wrote: >> On Mon, 2015-11-09 at 07:11 -0700, Jan Beulich wrote: >> On 09.11.15 at 15:01, wrote: SPIs are too numerous and not indivcidually as interesting. Make

Re: [Xen-devel] [PATCH] perfc: count number of explicit vcpu yields

On 11/09/2015 09:53 AM, Dario Faggioli wrote: On Mon, 2015-11-09 at 14:00 +, Ian Campbell wrote: Signed-off-by: Ian Campbell Reviewed-by: Dario Faggioli And, while we're here, I've been thinking since a while to try implementing an xl

Re: [Xen-devel] [PATCH] x86/P2M: consolidate handling of types not requiring a valid MFN

On 09/11/15 14:52, Jan Beulich wrote: > As noted regarding the mixture of checks in p2m_pt_set_entry(), > introduce an new P2M type group allowing to be used everywhere we "a new P2M" > just care about accepting operations with either a valid MFN or a type > permitting to be used without (valid)

[Xen-devel] RFC: PV vfb's and the handling of global vnc options

So I had a user report that he couldn't get the vnclisten option to work. It turns out he was using a PV guest, and had the following in his config file: vfb=[ 'type=vnc' ] vnclisten='0.0.0.0' After digging around in the code, it turns out that the following is accepted for PV guests: vnc=1

Re: [Xen-devel] [PATCH] xen: arm: perfc: count individual SGIs and PPIs

Hi, On 09/11/15 14:20, Ian Campbell wrote: > On Mon, 2015-11-09 at 07:11 -0700, Jan Beulich wrote: > On 09.11.15 at 15:01, wrote: >>> SPIs are too numerous and not indivcidually as interesting. >>> >>> Make the exists #IPIS counter x86 specific. >> >> I'd recommend

[Xen-devel] [PATCH v2] x86/PoD: tighten conditions for checking super page

Since calling the function isn't cheap, try to avoid the call when we know up front it won't help; see the code comment for details on those conditions. Signed-off-by: Jan Beulich --- v2: Adjust conditions and body of the if() to make them easier understandable, without

Re: [Xen-devel] [PATCH 1/3] xen/arm: introduce xen_read_wallclock

On Fri, 6 Nov 2015, Arnd Bergmann wrote: > > > > --- > > > > +static void xen_read_wallclock(struct timespec *ts) > > > > +{ > > > > + u32 version; > > > > + u64 delta; > > > > + struct timespec now; > > > > + struct shared_info *s = HYPERVISOR_shared_info; > > > > + struct

Re: [Xen-devel] [PATCH] perfc: count number of explicit vcpu yields

>>> On 09.11.15 at 15:00, wrote: > Signed-off-by: Ian Campbell Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 3/3] xen/arm: set the system time in Xen via the XENPF_settime hypercall

On Thu, 5 Nov 2015, Arnd Bergmann wrote: > On Thursday 05 November 2015 17:09:45 Stefano Stabellini wrote: > > If Linux is running as dom0, call XENPF_settime to update the system > > time in Xen on pvclock_gtod notifications. > > > > Signed-off-by: Stefano Stabellini

Re: [Xen-devel] [PATCH] perfc: count number of explicit vcpu yields

On Mon, 2015-11-09 at 14:00 +, Ian Campbell wrote: > Signed-off-by: Ian Campbell > Reviewed-by: Dario Faggioli And, while we're here, I've been thinking since a while to try implementing an xl interface for these counters... How bad of an

[Xen-devel] [PATCH] xen: arm: perfc: count individual SGIs and PPIs

SPIs are too numerous and not indivcidually as interesting. Make the exists #IPIS counter x86 specific. Signed-off-by: Ian Campbell Cc: jbeul...@suse.com --- xen/arch/arm/gic.c | 2 +- xen/arch/arm/irq.c | 4 ++--

Re: [Xen-devel] [PATCHv1 3/3] x86/ept: defer the invalidation until the p2m lock is released

>>> On 06.11.15 at 18:37, wrote: > --- a/xen/arch/x86/mm/mm-locks.h > +++ b/xen/arch/x86/mm/mm-locks.h > @@ -263,14 +263,21 @@ declare_mm_lock(altp2mlist) > */ > > declare_mm_rwlock(altp2m); > -#define p2m_lock(p) \ > -{

Re: [Xen-devel] [PATCH] xen: arm: perfc: count individual SGIs and PPIs

>>> On 09.11.15 at 15:01, wrote: > SPIs are too numerous and not indivcidually as interesting. > > Make the exists #IPIS counter x86 specific. I'd recommend not to - even if ARM doesn't want to use it, it's still a pretty generic thing. Jan

Re: [Xen-devel] [PATCH] x86/P2M: consolidate handling of types not requiring a valid MFN

>>> On 09.11.15 at 16:02, wrote: > On 09/11/15 14:52, Jan Beulich wrote: >> As noted regarding the mixture of checks in p2m_pt_set_entry(), >> introduce an new P2M type group allowing to be used everywhere we > > "a new P2M" > >> just care about accepting operations

[Xen-devel] [PATCH] arm64: Add the missing license macro in fdt module

From: Fu Wei Signed-off-by: Fu Wei --- grub-core/loader/arm64/fdt.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/grub-core/loader/arm64/fdt.c b/grub-core/loader/arm64/fdt.c index 5202c14..901bd7b 100644 --- a/grub-core/loader/arm64/fdt.c +++

Re: [Xen-devel] [PATCH] perfc: count number of explicit vcpu yields

On 09/11/15 14:00, Ian Campbell wrote: > Signed-off-by: Ian Campbell Reviewed-by: George Dunlap > --- > xen/common/schedule.c| 1 + > xen/include/xen/perfc_defn.h | 1 + > 2 files changed, 2 insertions(+) > > diff --git

[Xen-devel] [PATCH] x86/P2M: consolidate handling of types not requiring a valid MFN

As noted regarding the mixture of checks in p2m_pt_set_entry(), introduce an new P2M type group allowing to be used everywhere we just care about accepting operations with either a valid MFN or a type permitting to be used without (valid) MFN. Note that p2m_mmio_dm is not included in

Re: [Xen-devel] [PATCH v8 09/21] xen/x86: set the vPMU interface based on the presence of a lapic

>>> On 06.11.15 at 17:05, wrote: > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -5143,6 +5143,7 @@ static hvm_hypercall_t *const > hvm_hypercall64_table[NR_hypercalls] = { > HYPERCALL(sysctl), > HYPERCALL(domctl), > HYPERCALL(tmem_op), > +

[Xen-devel] [PATCH] perfc: count number of explicit vcpu yields

Signed-off-by: Ian Campbell --- xen/common/schedule.c| 1 + xen/include/xen/perfc_defn.h | 1 + 2 files changed, 2 insertions(+) diff --git a/xen/common/schedule.c b/xen/common/schedule.c index 292e9a0..86d6cc0 100644 --- a/xen/common/schedule.c +++

Re: [Xen-devel] [BUG] Boot failures with mpt2sas / Intel RMS25JB080 module

Hi Matthew, Can you please try with mpt2sas driver's max_msix_vectors set to one. ~Sreekanth On Fri, Nov 6, 2015 at 11:38 PM, Matthew Vernon wrote: > Hi, > > [These lists are in the MAINTAINERS file for mpt2sas; I hope this is > the correct place to report this problem.

Re: [Xen-devel] Critique of the Xen Security Process

On 11/6/15 11:22 AM, Joanna Rutkowska wrote: > Hello, > > Recently Xen has released the XSA-148 advisory [1] addressing a fatal bug in > the > hypervisor. The bug has been lurking there for the last 7 years! We, the Qubes > OS Project, have commented on this in our Security Bulletin #22 [2]. And

Re: [Xen-devel] Critique of the Xen Security Process

+1... so many great points here that ive thought many times its almost as if i could have written it great post! chris On Fri, Nov 6, 2015 at 12:22 PM, Joanna Rutkowska < joa...@invisiblethingslab.com> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello, > > Recently Xen has

Re: [Xen-devel] Xen 4.7 Development Update

On 09.11.2015 17:15, Wei Liu wrote: I accidentally deleted my old script, so I take the chance to change the tracking email a bit. Now this email only tracks big items for xen.git tree. Please reply for items you woulk like to see in 4.7 so that people have an idea what is going on and

[Xen-devel] [PATCH] arm64: Add the introduction of xen boot commands in docs/grub.texi

From: Fu Wei xen_hypervisor xen_linux xen_initrd xen_xsm Signed-off-by: Fu Wei --- docs/grub.texi | 38 ++ 1 file changed, 38 insertions(+) diff --git a/docs/grub.texi b/docs/grub.texi index

[Xen-devel] [linux-linus test] 63888: regressions - trouble: broken/fail/pass

flight 63888 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/63888/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rumpuserxen-i386 3 host-install(3) broken REGR. vs. 59254

Re: [Xen-devel] [PATCH v2] symbols.c: Avoid warn_unused_result build failure on fgets().

On 11/09/15 11:06, Riku Voipio wrote: > In commit: > > d37d63d symbols: prefix static symbols with their source file names > > An unchecked fgets was added. This causes a compile error at least > on ubuntu utopic: > > symbols.c: In function 'read_symbol': > symbols.c:181:3: error: ignoring

[Xen-devel] [libvirt test] 63903: regressions - FAIL

flight 63903 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/63903/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 5 libvirt-build fail REGR. vs. 63340 Tests which did not

[Xen-devel] [PATCH] arm64: clean up a useless variable in xen_boot.c

From: Fu Wei This patch delete "file_name_index" variable and related comment. They are for xen_module command which has been deleted. Signed-off-by: Fu Wei --- grub-core/loader/arm64/xen_boot.c | 19 +-- 1 file changed, 5 insertions(+),

Re: [Xen-devel] [PATCH v2 2/3] XENVER_build_id: Provide ld-embedded build-ids

On 11/06/2015 07:36 PM, Konrad Rzeszutek Wilk wrote: From: Martin Pohlack The mechanism to get this is via the XENVER_build_id and we add a new subsequent sub-command to retrieve the binary build-id. The hypercall allows an arbitrary size (the buffer and len is provided to

Re: [Xen-devel] [PATCH 3/3] xen/arm: set the system time in Xen via the XENPF_settime hypercall

On Monday 09 November 2015 14:10:22 Stefano Stabellini wrote: > On Thu, 5 Nov 2015, Arnd Bergmann wrote: > > On Thursday 05 November 2015 17:09:45 Stefano Stabellini wrote: > > > + now = __current_kernel_time(); > > > > We don't have __current_kernel_time64() yet, but it is trivial > > to add,

Re: [Xen-devel] [PATCH 3/3] xen/arm: set the system time in Xen via the XENPF_settime hypercall

On Mon, 9 Nov 2015, Stefano Stabellini wrote: > On Mon, 9 Nov 2015, Arnd Bergmann wrote: > > On Monday 09 November 2015 14:10:22 Stefano Stabellini wrote: > > > On Thu, 5 Nov 2015, Arnd Bergmann wrote: > > > > On Thursday 05 November 2015 17:09:45 Stefano Stabellini wrote: > > > > > + now =

Re: [Xen-devel] [PATCH 3/3] xen/arm: set the system time in Xen via the XENPF_settime hypercall

On Mon, 9 Nov 2015, Arnd Bergmann wrote: > On Monday 09 November 2015 14:10:22 Stefano Stabellini wrote: > > On Thu, 5 Nov 2015, Arnd Bergmann wrote: > > > On Thursday 05 November 2015 17:09:45 Stefano Stabellini wrote: > > > > + now = __current_kernel_time(); > > > > > > We don't have

Re: [Xen-devel] [RFC 00/29] Incomplete Kconfig conversion

On 11/9/15 9:06 AM, Konrad Rzeszutek Wilk wrote: > On Tue, Oct 06, 2015 at 05:11:51PM +0100, Ian Campbell wrote: >> On Tue, 2015-10-06 at 10:58 -0500, Doug Goldstein wrote: >>> You stated this better than I did. My goal is not to necessarily make >>> this like the Linux kernel where users toggle

Re: [Xen-devel] [PATCH v2 2/6] relocator: Do not use memory region if its starta is smaller than size

On 21.07.2015 08:42, Andrei Borzenkov wrote: > On Mon, Jul 20, 2015 at 5:35 PM, Daniel Kiper wrote: >> malloc_in_range() should not use memory region if its starta is smaller >> than size. Otherwise target wraps around and points to region which is >> usually not a RAM,

[Xen-devel] [PATCH v2 2/2] arm: export platform_op XENPF_settime64

From: Stefano Stabellini Call update_domain_wallclock_time at domain initialization, specifically in arch_set_info_guest for vcpu0, like we do on x86. Set time_offset_seconds to the number of seconds between phisical boot and domain initialization: it is going

[Xen-devel] [PATCH v2 1/2] xen: move wallclock functions from x86 to common

From: Stefano Stabellini Remove dummy arm implementation of wallclock_time. Use shared_info() in common code rather than x86-ism to access it, when possible. Define the static variable wc_sec, and the local variale sec in update_domain_wallclock_time, as

Re: [Xen-devel] [PATCH V8 3/7] libxl: add pvusb API

Chunyan Liu writes ("[PATCH V8 3/7] libxl: add pvusb API"): > Add pvusb APIs, including: > - attach/detach (create/destroy) virtual usb controller. > - attach/detach usb device > - list usb controller and usb devices > - some other helper functions Thanks for this. I have reviewed it in

[Xen-devel] [PATCH v2 0/2] wallclock time on arm

Hi all, this small series enables the wallclock time on arm and it consists mostly in code movement from x86 to common. Changes in v2: - remove stray blank lines - remove include - move version_update_* to include/xen/time.h - introduce ifdef to fix build issue in common/time.c - define wc_sec

Re: [Xen-devel] [PATCH v11 2/5] missing include asm/paravirt.h in cputime.c

On Thu, Nov 05, 2015 at 05:30:01PM +, Stefano Stabellini wrote: > On Thu, 5 Nov 2015, Peter Zijlstra wrote: > > How can this be missing? Things compile fine now, right? > > Fair enough. > > > > So please better explain why we do this change. > > asm/paravirt.h is included by one of the

Re: [Xen-devel] [PATCH v8 12/21] xen/x86: allow disabling the emulated PIT

>>> On 06.11.15 at 17:05, wrote: > Signed-off-by: Roger Pau Monné > Reported by: Boris Ostrovsky Acked-by: Jan Beulich ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH v2 1/6] gitignore: Ignore *.orig, *.rej and *.swp files

On Mon, Nov 09, 2015 at 04:34:20PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > On 09.11.2015 16:29, Daniel Kiper wrote: > > On Wed, Nov 04, 2015 at 01:03:56PM +0100, Vladimir 'phcoder' Serbinenko > > wrote: > >> Le 12 août 2015 11:04 AM, "Ian Campbell" a écrit

Re: [Xen-devel] [PATCH] perfc: count number of explicit vcpu yields

On Mon, 2015-11-09 at 15:23 +, Ian Campbell wrote: > On Mon, 2015-11-09 at 16:14 +0100, Dario Faggioli wrote: > > > > > As far as xl accessibility --- doesn't xenperf already read them > > > out? > > > > > Mmm... ISTR having tried without much luck, and having heard that > > it > > wasn't

Re: [Xen-devel] [PATCH] perfc: count number of explicit vcpu yields

On Mon, Nov 09, 2015 at 04:47:20PM +0100, Dario Faggioli wrote: > On Mon, 2015-11-09 at 15:23 +, Ian Campbell wrote: > > On Mon, 2015-11-09 at 16:14 +0100, Dario Faggioli wrote: > > > > > > > As far as xl accessibility --- doesn't xenperf already read them > > > > out? > > > > > > > Mmm...

Re: [Xen-devel] [PATCH 00/13] tools: do cleanups related to libxc python bindings

On 10/23/2015 03:04 PM, Juergen Gross wrote: This series is a combination of my previous patches: "libxc: remove most of tools/libxc/xc_dom_compat_linux.c" "tools: remove unused wrappers for python" I have split it up as requested by Ian Campbell, thus it consists of 13 patches instead just of

Re: [Xen-devel] [PATCH v2 1/6] gitignore: Ignore *.orig, *.rej and *.swp files

On 09.11.2015 16:29, Daniel Kiper wrote: > On Wed, Nov 04, 2015 at 01:03:56PM +0100, Vladimir 'phcoder' Serbinenko wrote: >> Le 12 août 2015 11:04 AM, "Ian Campbell" a écrit : >>> >>> >>> (Having written the below I see too late that this is a grub patch not a >>> Xen

Re: [Xen-devel] [PATCH v2 0/2] block/xen-blkfront: Support non-indirect grant with 64KB page granularity

Hi, Any comments on this new version? Regards, On 19/10/15 15:19, Julien Grall wrote: > Hi all, > > This is a follow-up on the previous discussion [1] related to guest using 64KB > page granularity which doesn't boot when the backend isn't using indirect > descriptor. > > This has been

Re: [Xen-devel] [PATCH v2 0/2] block/xen-blkfront: Support non-indirect grant with 64KB page granularity

On Mon, Nov 09, 2015 at 03:51:48PM +, Julien Grall wrote: > Hi, > > Any comments on this new version? I completly ignored thinking that the: c004a6f block/xen-blkfront: Make it running on 64KB page granularity 4f503fb block/xen-blkfront: split get_grant in 2 a7a6df2 block/xen-blkfront:

Re: [Xen-devel] [PATCH 1/3] xen/arm: introduce xen_read_wallclock

On Mon, 9 Nov 2015, Arnd Bergmann wrote: > On Monday 09 November 2015 13:53:30 Stefano Stabellini wrote: > > On Fri, 6 Nov 2015, Arnd Bergmann wrote: > > > I'm not quite sure about how the split between pvclock_wall_clock and > > > the delta works. Normally I'd expect that pvclock_wall_clock is

Re: [Xen-devel] [PATCH] perfc: count number of explicit vcpu yields

On Mon, 2015-11-09 at 16:14 +0100, Dario Faggioli wrote: >  > > As far as xl accessibility --- doesn't xenperf already read them out? > > > Mmm... ISTR having tried without much luck, and having heard that it > wasn't functional any longer, but maybe I'm confusing it with something > else. I'll

[Xen-devel] Xen 4.7 Development Update

I accidentally deleted my old script, so I take the chance to change the tracking email a bit. Now this email only tracks big items for xen.git tree. Please reply for items you woulk like to see in 4.7 so that people have an idea what is going on and prioritise accordingly. = Timeline = We now

Re: [Xen-devel] [PATCH 1/3] xen/arm: introduce xen_read_wallclock

On Monday 09 November 2015 13:53:30 Stefano Stabellini wrote: > On Fri, 6 Nov 2015, Arnd Bergmann wrote: > > I'm not quite sure about how the split between pvclock_wall_clock and > > the delta works. Normally I'd expect that pvclock_wall_clock is the > > wallclock > > time as it was at boot,

Re: [Xen-devel] [PATCH] perfc: count number of explicit vcpu yields

On Mon, 2015-11-09 at 10:02 -0500, Boris Ostrovsky wrote: > On 11/09/2015 09:53 AM, Dario Faggioli wrote: > > On Mon, 2015-11-09 at 14:00 +, Ian Campbell wrote: > > > Signed-off-by: Ian Campbell > > > > > Reviewed-by: Dario Faggioli > > >

Re: [Xen-devel] Xen 4.7 Development Update

On Mon, Nov 09, 2015 at 04:15:45PM +, Wei Liu wrote: > I accidentally deleted my old script, so I take the chance to change > the tracking email a bit. Now this email only tracks big items for > xen.git tree. Please reply for items you woulk like to see in 4.7 so > that people have an idea

Re: [Xen-devel] [PATCH 2/2] arm: export platform_op XENPF_settime

On Thu, 5 Nov 2015, Julien Grall wrote: > Hi Stefano, > > You forgot to CC Daniel for the XSM part. Please use > scripts/get_maintainers.pl to get the relevant maintainers. > > On 05/11/15 16:57, Stefano Stabellini wrote: > > Call update_domain_wallclock_time at domain initialization. > > It's

[Xen-devel] [PATCH v5 5/6] xen/arm: vgic: Introduce helpers to extract/update/clear/set vGIC register ...

and use them in the vGIC emulation. The GIC registers may support different access sizes. Rather than open coding the access for every registers, provide a set of helpers to access them. The caller will have to call vgic_regN_* where N is the size of the emulated registers. The new helpers

[Xen-devel] [PATCH v5 6/6] xen/arm: vgic-v3: Support 32-bit access for 64-bit registers

Based on 8.1.3 (IHI 0069A), unless stated otherwise, the 64-bit registers supports both 32-bit and 64-bits access. All the registers we properly emulate (i.e not RAZ/WI) supports 32-bit access. For RAZ/WI, it's also seems to be the case but I'm not 100% sure. Anyway, emulating 32-bit access for

[Xen-devel] [PATCH v5 4/6] xen/arm: vgic: Optimize the way to store the target vCPU in the rank

Xen is currently directly storing the value of GICD_ITARGETSR register (for GICv2) and GICD_IROUTER (for GICv3) in the rank. This makes the emulation of the registers access very simple but makes the code to get the target vCPU for a given vIRQ more complex. While the target vCPU of an vIRQ is

[Xen-devel] [PATCH v5 1/6] xen/arm: vgic-v2: Implement correctly ITARGETSR0 - ITARGETSR7 read-only

Each ITARGETSR register are 4-byte wide and the offset is in byte. The current implementation is computing the end of the range wrongly resulting to emulate only ITARGETSR{0,1} read-only. The rest will be treated as read-write. As 8 registers should be read-only, the end of the range should be

[Xen-devel] [PATCH v5 0/6] xen/arm: vgic: Support 32-bit access for 64-bit register

Hi all, This series aims to fix the 32-bit access on 64-bit registers. Some guest OS such as FreeBSD and Linux (ITS and recently 32-bit guest using GICv3) use 32-bit access and will crash at boot time. For all the changes see in each patch. Sincerely yours, Julien Grall (6): xen/arm:

[Xen-devel] [PATCH v5 3/6] xen/arm: vgic-v2: Don't ignore a write in ITARGETSR if one field is 0

The current implementation ignores the whole write if one of the field is 0. Although, based on the spec (4.3.12 IHI 0048B.b), 0 is a valid value when: - The interrupt is not wired in the distributor. From the Xen point of view, it means that the corresponding bit is not set in

Re: [Xen-devel] RFC: PV vfb's and the handling of global vnc options

On Mon, Nov 09, 2015 at 03:03:17PM +, George Dunlap wrote: > So I had a user report that he couldn't get the vnclisten option to > work. It turns out he was using a PV guest, and had the following in > his config file: > > vfb=[ 'type=vnc' ] > vnclisten='0.0.0.0' > > After digging around in

Re: [Xen-devel] [PATCH v2 1/6] gitignore: Ignore *.orig, *.rej and *.swp files

On Wed, Nov 04, 2015 at 01:03:56PM +0100, Vladimir 'phcoder' Serbinenko wrote: > Le 12 août 2015 11:04 AM, "Ian Campbell" a écrit : > > > > > > (Having written the below I see too late that this is a grub patch not a > > Xen one, a tag in the subject for such cross posted

[Xen-devel] [PATCH v5 2/6] xen/arm: vgic-v2: Handle correctly byte write in ITARGETSR

During a store, the byte is always in the low part of the register (i.e [0:7]). We are incorrectly masking the register by using a shift of the byte offset in the ITARGETSR while the byte is alwasy in r[0:7]. This will result in a target list equal to 0 which is ignored by the emulation. Because

Re: [Xen-devel] [PATCH v2 1/6] gitignore: Ignore *.orig, *.rej and *.swp files

On 09.11.2015 16:39, Daniel Kiper wrote: > On Mon, Nov 09, 2015 at 04:34:20PM +0100, Vladimir 'φ-coder/phcoder' > Serbinenko wrote: >> On 09.11.2015 16:29, Daniel Kiper wrote: >>> On Wed, Nov 04, 2015 at 01:03:56PM +0100, Vladimir 'phcoder' Serbinenko >>> wrote: Le 12 août 2015 11:04 AM,

Re: [Xen-devel] [PATCH 3/3] xen/arm: set the system time in Xen via the XENPF_settime hypercall

On Monday 09 November 2015 17:42:50 Stefano Stabellini wrote: > On Mon, 9 Nov 2015, Stefano Stabellini wrote: > > On Mon, 9 Nov 2015, Arnd Bergmann wrote: > > > On Monday 09 November 2015 14:10:22 Stefano Stabellini wrote: > > > > > > Just to make sure that this is actually the correct interface

Re: [Xen-devel] [PATCH v2 3/6] i386/relocator: Add grub_relocator64_efi relocator

On 20.07.2015 16:35, Daniel Kiper wrote: > Add grub_relocator64_efi relocator. It will be used on EFI 64-bit platforms > when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS. Relocator > will set lower parts of %rax and %rbx accordingly to multiboot2 specification. > On the other

Re: [Xen-devel] [PATCH 1/3] xen/arm: introduce xen_read_wallclock

On Monday 09 November 2015 17:14:24 Stefano Stabellini wrote: > On Mon, 9 Nov 2015, Arnd Bergmann wrote: > > On Monday 09 November 2015 13:53:30 Stefano Stabellini wrote: > > > On Fri, 6 Nov 2015, Arnd Bergmann wrote: > > > > I'm not quite sure about how the split between pvclock_wall_clock and >

Re: [Xen-devel] [PATCH v2 5/6] multiboot2: Add support for relocatable images

On 20.07.2015 16:35, Daniel Kiper wrote: > Signed-off-by: Daniel Kiper What is handling the actual relocation? Why doesn't this patch include support for ELF relocations? > --- > grub-core/loader/i386/multiboot_mbi.c |6 ++-- > grub-core/loader/multiboot.c |

Re: [Xen-devel] [qubes-devel] Re: Critique of the Xen Security Process

On Mon, Nov 09, 2015 at 04:31:58PM +, Franz wrote: > Perhaps a way out of this impasse is to put bounties on Xen security tasks > identified by Joanna and properly advertise these bounties to Xen users. > [snip] This is fundamentaly wrong idea. Security isn't something you can "apply" or put

Re: [Xen-devel] [qubes-devel] Re: Critique of the Xen Security Process

On Mon, Nov 9, 2015 at 12:11 PM, Jan Beulich wrote: > >>> On 06.11.15 at 18:22, wrote: > > 1. First of all, I wish Xen was somehow more defensively coded. To > provide > > some > > examples: > > > > a. In XSA-109 [5] there was a problem with the

[Xen-devel] [PATCH] efi: Fix booting failure with UEFI on ARM

From: Shannon Zhao Commit 9fd08b4 (efi: split out efi_get_gop()) splits out the codes getting the pointer to GOP as efi_get_gop(), but it doesn't initialize the variable handles and gop to NULL like what the original codes do. This will cause booting failure on ARM while

Re: [Xen-devel] [qubes-devel] Re: Critique of the Xen Security Process

As usual. Security, performance, convenience, price. Pick any mixture. As is usual for most software, developer convenience trumps most other considerations. I include ease of generating nice papers and jobs under developer convenience. Big players are much more concerned about performance, which

Re: [Xen-devel] [PATCH v9 00/17] Add VT-d Posted-Interrupts support

Thanks for your effort on this series and kindly ping.. Thanks, Feng > -Original Message- > From: Wu, Feng > Sent: Tuesday, November 3, 2015 4:43 PM > To: xen-devel@lists.xen.org > Cc: Wu, Feng > Subject: [PATCH v9 00/17] Add VT-d Posted-Interrupts support > > VT-d

[Xen-devel] [xen-unstable test] 63911: regressions - trouble: broken/fail/pass

flight 63911 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/63911/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-win7-amd64 3 host-install(3) broken REGR. vs. 63662

Re: [Xen-devel] [PATCH 3/4] docs: Document xenstore paths for domain hotplug features

>>> On 09.11.15 at 10:51, wrote: >> -Original Message- >> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] >> Sent: 06 November 2015 18:08 >> To: Paul Durrant; xen-de...@lists.xenproject.org >> Cc: Keir (Xen.org); Ian Campbell; Tim (Xen.org); Ian Jackson;

Re: [Xen-devel] 2016 Xen Dev Summit Location (input needed before next Thu)

On Fri, 2015-11-06 at 12:48 +, Lars Kurth wrote: > So we absolutely no easy option but to go for Toronto, unless > - We can find two smaller rooms on Tuesday Oct 4th, which I can > investigate > - Or to start the summit on the Sunday Oct 2nd and run it through > Monday Oct 3rd, which I can

[Xen-devel] [distros-debian-sid test] 38262: regressions - FAIL

flight 38262 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38262/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-amd64-sid-netboot-pvgrub 10 guest-start fail REGR. vs. 38239

Re: [Xen-devel] Hackathon 2016 Location Preferences

On Thu, 2015-11-05 at 15:21 +, Lars Kurth wrote: > Hi all, > > I wanted to do quick straw-poll regarding Hackathon Locations for > next year. Before I do this though, I wanted to let you know that the > 2016 Developer Summit will most likely be in Berlin in October (I am > in the process of

Re: [Xen-devel] [PATCH 1/4] docs: Document control features the can be advertised by guests...

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 09 November 2015 10:44 > To: Paul Durrant > Cc: Ian Campbell; Ian Jackson; xen-de...@lists.xenproject.org; Keir > (Xen.org); Tim (Xen.org) > Subject: Re: [PATCH 1/4] docs: Document control features the can be >

Re: [Xen-devel] [PATCH 3/4] docs: Document xenstore paths for domain hotplug features

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 09 November 2015 10:50 > To: Andrew Cooper; Paul Durrant; xen-de...@lists.xenproject.org > Cc: Ian Campbell; Ian Jackson; Keir (Xen.org); Tim (Xen.org) > Subject: RE: [Xen-devel] [PATCH 3/4] docs: Document xenstore

Re: [Xen-devel] [VOTE] Release cycle scheme

On Wed, Nov 04, 2015 at 03:46:59AM -0700, Jan Beulich wrote: > >>> On 02.11.15 at 14:47, wrote: > > So I propose we use the following scheme: > > > > - 6 months release cycle from unstable branch. > > - 4 months development. > > - 2 months freeze. > > - Eat into next

Re: [Xen-devel] [VOTE] Release cycle scheme

On 09/11/2015 11:04, "Wei Liu" wrote: >On Wed, Nov 04, 2015 at 03:46:59AM -0700, Jan Beulich wrote: >> >>> On 02.11.15 at 14:47, wrote: >> > So I propose we use the following scheme: >> > >> > - 6 months release cycle from unstable branch. >> > - 4

[Xen-devel] [linux-3.4 test] 63859: regressions - trouble: broken/fail/pass

flight 63859 linux-3.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/63859/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail REGR. vs. 62277

Re: [Xen-devel] [PATCH RFC] domain: Compile with lock_profile=y enabled.

>>> On 06.11.15 at 20:39, wrote: > On Thu, Nov 05, 2015 at 10:12:26AM -0700, Jan Beulich wrote: >> >>> On 02.11.15 at 18:12, wrote: >> > @@ -247,10 +248,12 @@ struct domain *alloc_domain_struct(void) >> > bits = _domain_struct_bits(); >>

Re: [Xen-devel] [PATCH] symbols.c: Avoid warn_unused_result build failure on fgets().

Hi, On 9 November 2015 at 10:10, Jan Beulich wrote: On 09.11.15 at 06:03, wrote: >> On 11/04/15 07:04, Jan Beulich wrote: >>> >>> On 04.11.15 at 12:39, wrote: >>> > In commit: >>> > >>> > d37d63d symbols: prefix static

[Xen-devel] questions about dirty bitmap

Hi,alls As we know,xen 4+ maintains a dirty bitmap. Snapshot or migration will use this bitmap. When the guest domain changes the memory page， VMM can capture it and set dirty bitmap to 1. I want to know the position in source code of this operation. And how did this process be realized？

[Xen-devel] [PATCH v2] symbols.c: Avoid warn_unused_result build failure on fgets().

In commit: d37d63d symbols: prefix static symbols with their source file names An unchecked fgets was added. This causes a compile error at least on ubuntu utopic: symbols.c: In function 'read_symbol': symbols.c:181:3: error: ignoring return value of 'fgets', declared with attribute

Re: [Xen-devel] [PATCH 1/4] docs: Document control features the can be advertised by guests...

>>> On 06.11.15 at 18:21, wrote: > ...via xenstore. > > XenServer already makes use of ~/control/feature-suspend being written > to advertise guest capability of responding to 'suspend' when written to > ~/control/shutdown and, since they are derived from XenServer

[Xen-devel] [linux-3.14 test] 63866: regressions - trouble: blocked/broken/fail/pass

flight 63866 linux-3.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/63866/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 5 kernel-build fail REGR. vs. 62648 Tests which are

[Xen-devel] Xen Security Advisory 156 (CVE-2015-5307, CVE-2015-8104) - x86: CPU lockup during exception delivery

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2015-5307,CVE-2015-8104 / XSA-156 version 2 x86: CPU lockup during exception delivery UPDATES IN VERSION 2 Minor title and text adjustment.

[Xen-devel] [linux-3.10 test] 63860: regressions - trouble: blocked/broken/fail/pass

flight 63860 linux-3.10 real [real] http://logs.test-lab.xenproject.org/osstest/logs/63860/ 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. 62642 build-armhf-pvops

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

flight 63803 xen-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/63803/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-migrupgrade 21 guest-migrate/src_host/dst_host fail REGR. vs. 63212 Tests

[Xen-devel] Mini-OS on ARM64

Hi all, With plenty of ugly hacks, mini-os is now able to boot on my arm64 board: (d37) - Mini-OS booting - (d37) - Setup CPU - (d37) - Setup booting pagetable - (d37) - MMU on - (d37) - Setup stack - (d37) - Jumping to C entry - (d37) Checking DTB at ffbff000... (d37) map_console, phys

Re: [Xen-devel] [PATCH 4/4] docs: Document xenstore paths for domain network address information

> -Original Message- > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: 06 November 2015 18:17 > To: Paul Durrant; xen-de...@lists.xenproject.org > Cc: Keir (Xen.org); Ian Campbell; Tim (Xen.org); Ian Jackson; Jan Beulich > Subject: Re: [Xen-devel] [PATCH 4/4] docs: Document

Re: [Xen-devel] [PATCH] x86/PoD: tighten conditions for checking super page

On Thu, Nov 5, 2015 at 4:43 PM, Jan Beulich wrote: On 02.11.15 at 17:29, wrote: >> * steal_for_cache may now be wrong. I realize that since now ram == 0 >> that all the subsequent "steal_for_cache" expressions will end up as >> "false" anyway,

Re: [Xen-devel] [PATCH] symbols.c: Avoid warn_unused_result build failure on fgets().

>>> On 09.11.15 at 06:03, wrote: > On 11/04/15 07:04, Jan Beulich wrote: >> >>> On 04.11.15 at 12:39, wrote: >> > In commit: >> > >> > d37d63d symbols: prefix static symbols with their source file names >> > >> > An unchecked fgets was added.

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

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

Re: [Xen-devel] [PATCH 3/4] docs: Document xenstore paths for domain hotplug features

> -Original Message- > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: 06 November 2015 18:08 > To: Paul Durrant; xen-de...@lists.xenproject.org > Cc: Keir (Xen.org); Ian Campbell; Tim (Xen.org); Ian Jackson; Jan Beulich > Subject: Re: [Xen-devel] [PATCH 3/4] docs: Document

Re: [Xen-devel] [VOTE] Release cycle scheme

On Mon, Nov 09, 2015 at 11:24:59AM +, Lars Kurth wrote: > > > On 09/11/2015 11:04, "Wei Liu" wrote: > > >On Wed, Nov 04, 2015 at 03:46:59AM -0700, Jan Beulich wrote: > >> >>> On 02.11.15 at 14:47, wrote: > >> > So I propose we use the following

  1   2   >