flight 62163 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62163/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 5 xen-install fail REGR. vs. 62015
test-amd64-amd64-
This is using Debian Jessie and grub 2.02~beta2-22 (with Debian patches
applied) and Xen 4.4.1
I originally posted a bug report with Debian but got the suggestion to
file bugs with upstream as well.
Debian bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799480
Note that my original
>>> Konrad Rzeszutek Wilk 09/21/15 8:06 PM >>>
>- Never figured out how much data we should save in the Xen's
>struct pci_device to see if we are 'stale'. Looking back I think
>we just need to do the interogation of the PCI capabilities and see
>if they have somehow changed (the ones we care about
>>> Ed Swierk 09/21/15 6:01 PM >>>
>The fundamental problem is that Xen tries to access extended config
>space in pci_add_device(), before the Dom0 finally figures out where
>MMCONFIG area is and makes the pci_mmcfg_reserved hypercall. The only
>robust solution seems to be for Xen to defer extende
> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Monday, September 21, 2015 10:12 PM
> To: Wu, Feng; George Dunlap
> Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew
> Cooper; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v
flight 62161 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62161/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qcow2 13 guest-saverestore fail REGR. vs. 60666
test-amd64-i386-xl-vhd
This run is configured for baseline tests only.
flight 37997 linux-3.16 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/37997/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 3 host-instal
On 09/21/2015 07:49 AM, Juergen Gross wrote:
On 09/15/2015 06:50 PM, Dario Faggioli wrote:
On Thu, 2015-08-20 at 20:16 +0200, Juergen Groß wrote:
On 08/18/2015 05:55 PM, Dario Faggioli wrote:
Hey everyone,
So, as a followup of what we were discussing in this thread:
[Xen-devel] PV-vNUMA i
On Mon, Sep 21, 2015 at 11:33:10AM +0100, Ian Campbell wrote:
>On Mon, 2015-09-21 at 17:08 +0800, Peng Fan wrote:
>> On Mon, Sep 21, 2015 at 11:10:11AM +0100, Julien Grall wrote:
>> > Hi Peng,
>> >
>> > On 21/09/15 08:07, Peng Fan wrote:
>> > > From "G6.2.29 CPSR, Current Program Status Register"
On Tue, 22 Sep 2015, Stefano Stabellini wrote:
> On Tue, 22 Sep 2015, Julien Grall wrote:
> > Hi Stefano,
> >
> > On 21/09/2015 23:51, Stefano Stabellini wrote:
> > > Changes in v6:
> > > - use vmap to map pages
> > > - free old module and update mod->start and mod->size from
> > > kernel_decompre
On Tue, 22 Sep 2015, Julien Grall wrote:
> Hi Stefano,
>
> On 21/09/2015 23:51, Stefano Stabellini wrote:
> > Changes in v6:
> > - use vmap to map pages
> > - free old module and update mod->start and mod->size from
> > kernel_decompress
>
> I was expecting you to drop my Reviewed-by given those
branch xen-unstable
xen branch xen-unstable
job test-armhf-armhf-xl-raw
test xen-boot
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found an
flight 62156 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62156/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate
fail REGR. vs. 61627
R
Hi Konrad,
On 09/09/2015 16:02, Konrad Rzeszutek Wilk wrote:
Konrad, would you like me to resend the patch with the modified commit
message, or do you plan to amend it yourself while committing?
I will amend it. Thanks!
What the status for this patch?
Regards,
--
Julien Grall
Hi Stefano,
On 21/09/2015 23:51, Stefano Stabellini wrote:
Changes in v6:
- use vmap to map pages
- free old module and update mod->start and mod->size from
kernel_decompress
I was expecting you to drop my Reviewed-by given those changes.
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/ker
Free the memory used for the compressed kernel and update the relative
mod->start and mod->size parameters with the uncompressed ones.
To decompress the kernel, allocate memory from dommheap, because freeing
the modules is done by calling init_heap_pages, which frees to domheap.
Map these pages us
The current gunzip code to decompress the Dom0 kernel is implemented in
inflate.c which is included by bzimage.c.
I am looking to doing the same on ARM64 but there is quite a bit of
boilerplate definitions that I would need to import in order for
inflate.c to work correctly.
Instead of copying/pa
Hi all,
this patch series introduces support for gzipped kernels, such as the
standard Image.gz format used by Linux on arm64 by default, in Xen on
arm. Without it, Xen cannot load the default kernel shipped by distros,
such as CentOS 7.
Stefano Stabellini (2):
xen: move perform_gunzip to
flight 62151 qemu-upstream-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62151/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-vhd9 debian-di-install fail REGR. vs. 60577
test-am
This run is configured for baseline tests only.
flight 37996 qemu-upstream-4.3-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/37996/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd
On Mon, Sep 21, 2015 at 11:16 AM, Andy Lutomirski wrote:
>
> In the interest of sanity, I want to drop the "native_", too
Yes. I think the only reason it exists is to have that wrapper layer
for PV. And that argument just goes away if you just make the
non-inline helper function do all the PV log
On Mon, Sep 21, 2015 at 11:16:30AM -0700, Andy Lutomirski wrote:
> In the interest of sanity, I want to drop the "native_", too, since
> there appear to be few or no good use cases for native_read_msr as
> such. I'm tempted to add new functions read_msr and write_msr that
> forward to rdmsrl_safe
On Mon, Sep 21, 2015 at 9:36 AM, Linus Torvalds
wrote:
> On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote:
>>
>> Linus, what's your preference?
>
> So quite frankly, is there any reason we don't just implement
> native_read_msr() as just
>
>unsigned long long native_read_msr(unsigned int ms
On Mon, Sep 21, 2015 at 08:58:44AM -0700, Ed Swierk wrote:
> After testing this change on different platforms, I'm finding some
> complications.
>
> As I understand it, the BIOS is supposed to mark the MMCONFIG area
> reserved in the E820 table no matter what. And if the ACPI DSDT
> includes an MC
On Mon, Sep 21, 2015 at 9:49 AM, Arjan van de Ven wrote:
> On 9/21/2015 9:36 AM, Linus Torvalds wrote:
>>
>> On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote:
>>>
>>>
>>> Linus, what's your preference?
>>
>>
>> So quite frankly, is there any reason we don't just implement
>> native_read_msr() a
On 21/09/15 18:13, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [PATCH RFC tools 1/6] tools: Refactor
> "xentoollog" into its own library"):
>> On 21/09/15 17:17, Ian Jackson wrote:
>>> Do you mean that statement expressions (originally a GNU extension)
>>> should be avoided in tool
On Mon, Sep 21, 2015 at 9:49 AM, Arjan van de Ven wrote:
>>
>> How many msr reads are so critical that the function call
>> overhead would matter?
>
> if anything qualifies it'd be switch_to() and friends.
Is there anything else than the FS/GS_BASE thing (possibly hidden
behind inlines etc that I
On 9/21/2015 9:36 AM, Linus Torvalds wrote:
On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote:
Linus, what's your preference?
So quite frankly, is there any reason we don't just implement
native_read_msr() as just
unsigned long long native_read_msr(unsigned int msr)
{
int er
Andrew Cooper writes ("Re: [Xen-devel] [PATCH RFC tools 1/6] tools: Refactor
"xentoollog" into its own library"):
> On 21/09/15 17:17, Ian Jackson wrote:
> > Do you mean that statement expressions (originally a GNU extension)
> > should be avoided in tools code ? A quick git-grep discovered that
On 21/09/15 17:17, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [PATCH RFC tools 1/6] tools: Refactor
> "xentoollog" into its own library"):
>> On 10/06/15 12:36, Ian Campbell wrote:
>>> +
>>> +#define XTL_NEW_LOGGER(LOGGER,buffer) ({\
>>> +xentoo
This run is configured for baseline tests only.
flight 37994 qemu-upstream-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/37994/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 6 xe
On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote:
>
> Linus, what's your preference?
So quite frankly, is there any reason we don't just implement
native_read_msr() as just
unsigned long long native_read_msr(unsigned int msr)
{
int err;
unsigned long long val;
val = na
Andrew Cooper writes ("Re: [Xen-devel] [PATCH RFC tools 1/6] tools: Refactor
"xentoollog" into its own library"):
> On 10/06/15 12:36, Ian Campbell wrote:
> > +
> > +#define XTL_NEW_LOGGER(LOGGER,buffer) ({\
> > +xentoollog_logger_##LOGGER *new_consumer;
Ian Campbell writes ("[PATCH OSSTEST] Debian: Avoid uninitialised string warn
when getting host firmware property"):
> Signed-off-by: Ian Campbell
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Ian Campbell writes ("[PATCH OSSTEST] Debian: handle move of ip(8) to /sbin in
Jessie"):
> Unfortunately udev treats non-absolute commands as relative to
> /lib/udev rather than consulting $PATH, so we have to figure out the
> path based on the suite.
Bah.
Tempting to say `use env(1)' but of cou
It is going to be in QEMU 2.5 and qemu-xen 4.7.
On Mon, 21 Sep 2015, Chen, Tiejun wrote:
> Stefano,
>
> I have two questions,
>
> #1. Which qemu version is this igd stuff going into? 2.6?
> #2. Is this igd stuff going into qemu-xen inside xen? Any plan to go into xen
> 4.6?
>
> Thanks
> Tiejun
After testing this change on different platforms, I'm finding some
complications.
As I understand it, the BIOS is supposed to mark the MMCONFIG area
reserved in the E820 table no matter what. And if the ACPI DSDT
includes an MCFG record, then it should also include a PNP0C0x record
for the MMCONFI
Hi Ian,
I think this series is all acked. Would it be possible to merge it in
unstable?
Regards,
On 14/09/15 16:32, Julien Grall wrote:
> Hi all,
>
> This small patch series allow Xen to run on platform reporting GICv4
> in the GIC*_PIDR2.
>
> Sincerely yours,
>
> Julien Grall (2):
> xen/ar
On Wed, 2015-07-15 at 16:46 +0100, Ian Campbell wrote:
> diff --git a/tools/libxenevtchn/include/xenevtchn.h
> [...]
> +/* A port identifier is guaranteed to fit in 31 bits. */
> +typedef int evtchn_port_or_error_t;
>
[...]
> +/*
> + * Returns a new event port awaiting interdomain connection from
>>> On 04.09.15 at 14:09, wrote:
First of all - I suppose it is intentional for this to not consider the Dom0
side (yet)?
> --- a/tools/libxc/xc_dom_x86.c
> +++ b/tools/libxc/xc_dom_x86.c
> @@ -560,7 +560,70 @@ static int alloc_magic_pages_hvm(struct xc_dom_image
> *dom)
> xc_hvm_param_set
>>> On 04.09.15 at 14:09, wrote:
> Allow the usage of the VCPUOP_initialise, VCPUOP_up, VCPUOP_down and
> VCPUOP_is_up hypercalls from HVM guests.
>
> This patch introduces a new structure (vcpu_hvm_context) that should be used
> in conjuction with the VCPUOP_initialise hypercall in order to init
Hi Vijay,
On 18/09/15 14:09, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> This patch introduces virtual ITS driver with following
> functionality
> - Introduces helper functions to manage device table and
>ITT table in guest memory
> - Helper function to handle virtual ITS devi
On Mon, Sep 21, 2015 at 09:09:28AM -0400, Boris Ostrovsky wrote:
> For PV guests these registers are set up by hypervisor and thus
> should not be written by the guest. The comment in xen_write_msr_safe()
> says so but we still write the MSRs, causing the hypervisor to
> print a warning.
>
> Signe
This run is configured for baseline tests only.
flight 37995 xen-4.4-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/37995/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-amd64-rumpuserxen-amd64 1 build-
Hi Vijay,
On 18/09/15 14:09, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> Initialize physical ITS if HW supports LPIs.
>
> Signed-off-by: Vijaya Kumar K
> ---
> v7: - Export lpi support information to vgic-v3 driver from gic-v3.
> - Drop gic_lpi_supported() helper function
>
Signed-off-by: Ian Campbell
---
Osstest/Debian.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 8675922..a8b62ca 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -1169,7 +1169,7 @@ END
preseed_microcode($ho,$sfx);
Unfortunately udev treats non-absolute commands as relative to
/lib/udev rather than consulting $PATH, so we have to figure out the
path based on the suite.
Without this the force-mac-address workaround (needed on Arndale)
doesn't work.
Signed-off-by: Ian Campbell
---
ts-host-install | 4 +++-
M A Young writes ("Re: DRAFT XSA 142 - libxl fails to honour readonly flag on
disks with qemu-xen"):
> Of course you still need a separate patch for xen 4.5.1 and earlier as the
> xsa142.patch file attached is only valid for xen 4.6.0. Replacing
> ERROR_INVAL with NULL works for xen 4.5.1 and co
On 21/09/15 14:58, Razvan Cojocaru wrote:
> Hello,
Hi Razvan,
> This doesn't have much to do with this series, but when running
> scripts/get-maintainer.pl on my patches, I got "Stefano Stabellini
> " for my first patch, and "Stefano
> Stabellini " for the second one (i.e. the
> second address is
On 18/09/15 14:09, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> Move vgic rank locking inside get_irq_priority callback.
> LPIs does not have vgic rank lock for reading LPI priority.
> So make generic vgic code cleaner.
The commit message is not clear. I would rewrite like that:
"Th
On 09/21/2015 10:36 AM, Jan Beulich wrote:
On 04.09.15 at 14:08, wrote:
Hmm - this seems questionable to me: Isn't the vPMU an optional
feature anyway? I.e. doesn't need separate handling here? Boris?
It is optional system-wise, not per-guest, which is what I think Roger
is trying to do. I i
flight 62149 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62149/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 18 guest-start.2 fail REGR. vs.
62000
Regressions which ar
>>> On 04.09.15 at 14:09, wrote:
> --- a/xen/include/public/elfnote.h
> +++ b/xen/include/public/elfnote.h
> @@ -200,9 +200,18 @@
> #define XEN_ELFNOTE_SUPPORTED_FEATURES 17
>
> /*
> + * Physical entry point into the kernel.
> + *
> + * 32bit entry point into the kernel. Xen will use this entr
* DRAFT DRAFT DRAFT *
Xen Security Advisory XSA-142
libxl fails to honour readonly flag on disks with qemu-xen
ISSUE DESCRIPTION
=
Callers of libxl can specify that a disk should be read-only to the
guest. However, there is no code in libxl t
On Mon, 2015-09-21 at 08:12 -0600, Jan Beulich wrote:
> > > > On 17.09.15 at 18:52, wrote:
> > This essentially reverts c/s 2037f2adb "x86: introduce
> > alloc_vcpu_guest_context()", including the newer arm bits, but achieves
> > the same end goal by using the newer vmalloc() infrastructure.
> >
Hi Vijay,
Title: I would replace "Plumbing" by "Plumb"
On 18/09/15 14:08, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> Change callbacks gic_host_irq_type and gic_guest_irq_type
> to gic_get_host_irq_type and gic_get_guest_irq_type
> in gic_hw_operations, which returns hw_irq_control
There are 2 error information:
1. The following is misleading, but correct. So ignore it.
ERROR[VTPM]: LoadKey failure: Unrecognized uuid!
405ffc60-6b15-48e0-921a-d6645db0be03
ERROR[VTPM]: Failed to load key
2. This is maybe the problem:
ERROR[VTPM]: LoadKey failure: Unrecognized uuid!
Hi Vijay,
On 18/09/15 14:08, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> Implement hw_irq_controller callbacks required to
> handle LPIs.
>
> Signed-off-by: Vijaya Kumar K
With the 3 changes requested below:
Reviewed-by: Julien Grall
> ---
> xen/arch/arm/gic-v3-its.c
>>> On 04.09.15 at 14:08, wrote:
Hmm - this seems questionable to me: Isn't the vPMU an optional
feature anyway? I.e. doesn't need separate handling here? Boris?
Jan
> Signed-off-by: Roger Pau Monné
> Acked-by: Andrew Cooper
> Cc: Jan Beulich
> Cc: Andrew Cooper
> ---
> Changes since v4:
>
>>> On 04.09.15 at 14:08, wrote:
> @@ -425,6 +431,9 @@ void vpic_reset(struct domain *d)
>
> void vpic_init(struct domain *d)
> {
> +if ( !has_vpic(d) )
> +return;
vpic_reset() above this function as well as functions further down
in the source file aren't static, yet you aren't a
At 20:47 +0100 on 16 Sep (1442436442), Andrew Cooper wrote:
> On 16/09/2015 09:47, Ross Lagerwall wrote:
> > Since commit 191b3f3344ee ("p2m/ept: enable PML in p2m-ept for
> > log-dirty"), the A and D bits of EPT paging entries are set
> > unconditionally, regardless of whether PML is enabled or no
Ian Jackson writes ("Re: [OSSTEST PATCH 19/26] ts-debian-hvm-install: Cope with
images containing only isolinux"):
> Ian Campbell writes ("Re: [OSSTEST PATCH 19/26] ts-debian-hvm-install: Cope
> with images containing only isolinux"):
> > Acked-by: Ian Campbell
>
> Thanks, but given the circmst
On Mon, 2015-09-21 at 12:22 +, Wu, Feng wrote:
>
> > -Original Message-
> > From: George Dunlap [mailto:george.dun...@citrix.com]
> > You also need to check that local_events_need_delivery() will
> > return
> > "true" if you get an interrupt between that time and entering the
> > hype
Hi Vijay,
On 18/09/15 14:08, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> Helper function gic_is_lpi() is used to find
> if irq is lpi or not. For GICv2 platforms this function
> returns number of irq ids which represents only number of line irqs.
> For GICv3 platform irq ids are cal
flight 62148 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62148/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail
REGR. vs.
>>> On 21.09.15 at 16:03, wrote:
On 21.09.15 at 20:04, < jbeul...@suse.com > wrote:
>> >>> On 21.09.15 at 11:46, wrote:
>> >>> >>> On 21.09.15 at 16:51, < jbeul...@suse.com > wrote:
>> >>- Anything else?
>> >
>> >
>> > Just test the extreme case. The ATS specification mandates a timeout
>>
>>> On 21.09.15 at 16:09, wrote:
> On 21/09/15 15:00, Jan Beulich wrote:
> On 21.09.15 at 15:51, wrote:
>>> On 21/09/15 14:04, Jan Beulich wrote:
>>> On 17.09.15 at 13:40, wrote:
> +/* Mask out features not currently understood by Xen. */
> +eax &= (cpufeat_mask(X86_FEATU
>>> On 17.09.15 at 18:52, wrote:
> This essentially reverts c/s 2037f2adb "x86: introduce
> alloc_vcpu_guest_context()", including the newer arm bits, but achieves
> the same end goal by using the newer vmalloc() infrastructure.
>
> For both x86 and ARM, {alloc,free}_vcpu_guest_context() become a
flight 62150 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62150/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 9a470dae60ed0c57afdf61342616dd1768ba5ec8
baseline version:
ovmf 2f667c5488c81924861901d4d7c6f4bb170
On Mon, 2015-09-21 at 13:50 +, Wu, Feng wrote:
>
> > -Original Message-
> > From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> > Note that, in case of preemptions, we are switching from a non-idle
> > vcpu to another, non-idle, vcpu, so lazy context switching to the
> > idle
>
On 21/09/15 15:00, Jan Beulich wrote:
On 21.09.15 at 15:51, wrote:
On 21/09/15 14:04, Jan Beulich wrote:
On 17.09.15 at 13:40, wrote:
Jan: I have opted for adding leaf 8 rather than reusing leaf 2, due to the
uncertainty with how this information is exposed in libxl. This patch
introduces
George / Tim,
Could you help me review these memory patches? Thanks!
-Quan
> -Original Message-
> From: Xu, Quan
> Sent: Wednesday, September 16, 2015 9:24 PM
> To: andrew.coop...@citrix.com; Dong, Eddie; ian.campb...@citrix.com;
> ian.jack...@eu.citrix.com; jbeul...@suse.com; Nakajima,
>>> On 21.09.15 at 20:04, < jbeul...@suse.com > wrote:
> >>> On 21.09.15 at 11:46, wrote:
> >>> >>> On 21.09.15 at 16:51, < jbeul...@suse.com > wrote:
> >>- Anything else?
> >
> >
> > Just test the extreme case. The ATS specification mandates a timeout
> > of 1 _minute_ for cache flush, even thou
Use unsigned and bool_t as appropriate.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -662,12 +662,12 @@ ept_set_entry(struct p2m_domain *p2m, un
{
ept_entry_t *table, *ept_entry = NULL;
unsigned long gfn_remainder = gfn;
-int i, tar
... instead of recalculating them.
At once clean up formatting of the touched code and drop a stray loop
local variable shadowing a function scope one.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -655,17 +655,13 @@ p2m_pt_set_entry(struct p2m_doma
In the EPT case permission changes should also result in updates or
TLB flushes.
In the NPT case the old MFN does not depend on the new entry being
valid (but solely on the old one), and the need to update or TLB-flush
again also depends on permission changes.
In the shadow mode case, iommu_hap_p
>>> On 21.09.15 at 15:51, wrote:
> On 21/09/15 14:04, Jan Beulich wrote:
> On 17.09.15 at 13:40, wrote:
>>> Jan: I have opted for adding leaf 8 rather than reusing leaf 2, due to the
>>> uncertainty with how this information is exposed in libxl. This patch
>>> introduces no change with how t
1: p2m: tighten conditions of IOMMU mapping updates
2: p2m-pt: use pre-calculated IOMMU flags
3: p2m-ept: adjust some types in ept_set_entry()
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Hello,
This doesn't have much to do with this series, but when running
scripts/get-maintainer.pl on my patches, I got "Stefano Stabellini
" for my first patch, and "Stefano
Stabellini " for the second one (i.e. the
second address is missing the ".eu" part).
I don't know if this is intended, so th
On 21/09/15 14:04, Jan Beulich wrote:
On 17.09.15 at 13:40, wrote:
Jan: I have opted for adding leaf 8 rather than reusing leaf 2, due to the
uncertainty with how this information is exposed in libxl. This patch
introduces no change with how the information is represented in userspace.
Mind e
> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Monday, September 21, 2015 9:32 PM
> To: Wu, Feng; George Dunlap
> Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew
> Cooper; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v7
Hi Vijay,
On 18/09/15 14:08, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> Add APIs to add devices to RB-tree, assign and remove
> devices to domain.
>
> Signed-off-by: Vijaya Kumar K
> ---
> v7: - Added check for domain in its_assign_device() to avoid
> assigning device to Do
Hello,
This series adds two minor patches. The first one allows finer-grained
control over the emulation behaviour of REP instructions. Previously,
once vm_event-based emulation was enabled, no optimizations were allowed.
However, this has a performance impact on the monitored guest, so I've
added
Previously, if vm_event emulation support was enabled, then REP
optimizations were disabled when emulating REP-compatible
instructions. This patch allows fine-tuning of this behaviour by
providing a dedicated libxc helper function.
Signed-off-by: Razvan Cojocaru
---
Changes since V1:
- Renamed
On Mon, 2015-09-21 at 11:59 +, Wu, Feng wrote:
>
> > -Original Message-
> > From: George Dunlap [mailto:george.dun...@citrix.com]
> > > I think the handling for lazy context switch is not only for the
> > > blocking case,
> > > we still need to do something for lazy context switch eve
A previous version of this patch dealing with support for skipping
the current instruction when a vm_event response requested it
computed the instruction length in the hypervisor, adding non-trivial
code dependencies. This patch allows a userspace vm_event client to
simply request that the guest's
>>> On 17.09.15 at 18:08, wrote:
> We shouldn't have multiple different top level command line options. In
> particular, having "mwait-idle" and "intel_pstate" seems wrong, given a
> perfectly good "cpufreq=" option.
"mwait-idle" is C-state related.
Jan
___
>>> On 17.09.15 at 17:38, wrote:
> On 14/09/15 03:32, Wei Wang wrote:
>> Move the driver register function to
>> the cpufreq.c.
>>
>> Signed-off-by: Wei Wang
>> ---
>> xen/drivers/cpufreq/cpufreq.c | 15 +++
>> xen/include/acpi/cpufreq/cpufreq.h | 27 +--
flight 62146 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62146/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 62042
test-armhf-armhf-xl-vh
For PV guests these registers are set up by hypervisor and thus
should not be written by the guest. The comment in xen_write_msr_safe()
says so but we still write the MSRs, causing the hypervisor to
print a warning.
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/enlighten.c | 1 +
1 file change
On 18/09/15 14:08, vijay.kil...@gmail.com wrote:
> +static void its_lpi_free(struct its_device *dev)
> +{
> +int lpi;
> +
> +spin_lock(&lpi_lock);
> +
> +for ( lpi = dev->event_map.lpi_base;
> + lpi < (dev->event_map.lpi_base + dev->event_map.nr_lpis);
> + lpi += IRQS_
On Mon, 21 Sep 2015, Xen.org security team wrote:
> * DRAFT DRAFT DRAFT *
>
> Xen Security Advisory XSA-142
>
> ...
>
> xsa142.patch Xen 4.3.x and later
>
> $ sha256sum xsa142*.patch
> de0d6d19becac199037dce5a6a49e35cb7de5c99b8e2950600ed71fdc2d5a752
>>> On 17.09.15 at 13:40, wrote:
> Jan: I have opted for adding leaf 8 rather than reusing leaf 2, due to the
> uncertainty with how this information is exposed in libxl. This patch
> introduces no change with how the information is represented in userspace.
Mind explaining this "uncertainty"? I
On Mon, 2015-09-21 at 13:28 +0100, Julien Grall wrote:
> Hi Ian,
>
> On 21/09/15 12:54, Ian Campbell wrote:
> > On Fri, 2015-09-18 at 09:53 +0100, Ian Campbell wrote:
> > > On Thu, 2015-09-17 at 19:00 +0100, Julien Grall wrote:
> > > > On GICv2, the GIC virtual CPU interface is at minimum 8KB. Due
Ian Campbell writes ("Re: DRAFT XSA 142 - libxl fails to honour readonly flag
on disks with qemu-xen"):
> On Tue, 2015-09-15 at 16:22 +, Xen.org security team wrote:
> > VULNERABLE SYSTEMS
> > ==
> >
> [...]
> > Only systems using libxl or libxl-based toolstacks are vulnerable
* DRAFT DRAFT DRAFT *
Xen Security Advisory XSA-142
libxl fails to honour readonly flag on disks with qemu-xen
ISSUE DESCRIPTION
=
Callers of libxl can specify that a disk should be read-only to the
guest. However, there is no code in libxl t
>>> On 16.09.15 at 22:31, wrote:
> I think the lspci -v output is the same in both cases with the exception
> of the xhci_pci which is not present in the Native case lspci -v output.
> xhci_pci is built into the kernel. The same kernel/system is used with
> this system when booted with Dom0 and na
TL;DR: There are issues, but IMHO switching can be justified.
On Thu, 2015-09-03 at 09:59 +0100, Ian Campbell wrote:
> TL;DR: There are issues which need fixing first...
>
> On Fri, 2015-08-21 at 17:24 +, osstest service owner wrote:
> > flight 60785 linux-4.1 real [real]
> > http://logs.test
>>> On 18.09.15 at 08:53, wrote:
> flight 62047 xen-4.4-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/62047/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-raw9 debian-di-inst
>>> On 16.09.15 at 21:47, wrote:
> On 16/09/2015 09:47, Ross Lagerwall wrote:
>> Since commit 191b3f3344ee ("p2m/ept: enable PML in p2m-ept for
>> log-dirty"), the A and D bits of EPT paging entries are set
>> unconditionally, regardless of whether PML is enabled or not. This
>> causes a regressio
1 - 100 of 173 matches
Mail list logo
