On 15/12/16 19:41, Dario Faggioli wrote:
> On Thu, 2016-12-08 at 11:38 +0100, Juergen Gross wrote:
>> So you really solved the following problem in credit2?
>>
>> You have three domains with 2 vcpus each and different weights. Run
>> them
>> on 3 physical cpus with following pinning:
>>
>> dom1: pc
On Tue, Nov 29, 2016 at 12:29 AM, Julien Grall wrote:
>
>
> On 26/11/16 06:59, Vijay Kilari wrote:
>>
>> Hi,
>
>
> Hi Vijay,
>
> This mail is mixing two distinct problems:
> 1) Making Xen NUMA-aware
> 2) Make DOM0 NUMA-aware
>
> As mentioned in another part of this thread, those pr
This run is configured for baseline tests only.
flight 68226 xen-4.4-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68226/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-320 xtf/test-hvm32-
On 15/12/16 18:36, Borislav Petkov wrote:
> On Thu, Dec 15, 2016 at 12:27:49PM -0500, Boris Ostrovsky wrote:
>> It will probably fix it but I don't think we want this: it's a
>> build-time solution. Most kernels have XEN on even though they are
>> booted bare-metal.
>
> Lemme tell you want I want:
>>> On 15.12.16 at 18:10, wrote:
> %ss, %fs and %gs can be calculated by directly masking the opcode. %es and
> %ds cant, but the calculation isn't hard.
>
> Use seg rather than dst.val for storing the calculated segment, which is
> appropriately typed. Drop the sel local variable entirely and
VMID space is increased to 16-bits from 8-bits in ARMv8 8.1 revision.
This allows more than 256 VMs to be supported by Xen.
This change adds support for 16-bit VMIDs in Xen based on whether the
architecture supports it.
Signed-off-by: Bhupinder Thakur
---
xen/arch/arm/p2m.c | 52 ++
Since VMIDs are related to 2nd stage address translation, it makes more sense
to move the call to p2m_vmid_allocator_init(), which initializes the vmid
allocation bitmap, inside setup_virt_paging(), where 2nd stage address
translation
is set up.
Signed-off-by: Bhupinder Thakur
Reviewed-by: Julie
flight 103352 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103352/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 6 xen-boot fail REGR. vs. 101737
test-amd64-amd64-xl-q
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-qemuu-nested-intel
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-tradi
flight 103439 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103439/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 103284
Tests which
This run is configured for baseline tests only.
flight 68227 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68227/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf aaa61995af9e0b65c37bdad6796867760fa1d5fe
baseline v
Yu Zhang,
As we discussed, attached is the draft of the change to the
p2m_change_entry_type changes I was working on.
Currently, Xen keeps track of what certain types “should” be, via a list of
logdirty ranges as well as mmio ranges.
This patch series attempts to do the opposite: to make “p2m
> On Dec 16, 2016, at 12:43 AM, Jan Beulich wrote:
>
On 09.12.16 at 16:44, wrote:
>> + * - Any loop needs to be accompanied by calls to elf_iter_ok (or
>> + *elf_iter_ok_counted).
>> + *
>> + *Rationale: the image must not be able to cause libelf to do
>> + *unbounded
On Fri, Dec 16, 2016 at 7:20 AM, Ronald Rojas wrote:
> Create a basic Makefile to build and install libxenlight Golang
> bindings. Also add a template.
What's this template again?
>
> ---
>
> Eventually this patch will contain the actual bindings package; for
> now it just includes a stub packa
> On Dec 16, 2016, at 11:20 AM, Doug Goldstein wrote:
>
> On 12/15/16 5:20 PM, Ronald Rojas wrote:
>> Create a basic Makefile to build and install libxenlight Golang
>> bindings. Also add a template.
>>
>> ---
>>
>> Eventually this patch will contain the actual bindings package; for
>> now it
On Fri, 16 Dec 2016, Borislav Petkov wrote:
> What for? We don't want to run the microcode loader on xen at all.
Or under KVM, or any other hypervisor, really.
--
Henrique Holschuh
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen
On 12/15/2016 06:04 PM, Borislav Petkov wrote:
On Thu, Dec 15, 2016 at 05:56:44PM -0500, Boris Ostrovsky wrote:
With CONFIG_PARAVIRT (which I suspect you don't have on) cpuid() is a
call via a pointer, you can see it, for example, if you disassemble
load_ucode_amd_bsp(). And we don't have pagi
On 12/15/16 5:20 PM, Ronald Rojas wrote:
> Create a basic Makefile to build and install libxenlight Golang
> bindings. Also add a template.
>
> ---
>
> Eventually this patch will contain the actual bindings package; for
> now it just includes a stub package.
>
So I'm curious why the interest t
flight 103429 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103429/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 103284
Tests which
flight 103365 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103365/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-3 20 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 102521
test-xtf-amd64-
On Wed, 2016-12-14 at 03:39 +0100, George Dunlap wrote:
> > On Dec 10, 2016, at 4:18 AM, Stefano Stabellini > .org> wrote:
> > > > The issue with spreading interrupts migrations over time is
> > > > that it makes
> > > > interrupt latency less deterministic. It is OK, in the uncommon
> > > > case
On Thu, 2016-12-15 at 23:39 +0530, Praveen Kumar wrote:
> The patch gets rid of a redundant check in csched_vcpu_acct. In fact,
> the function is only called from csched_tick, which already checks
> that current is not the idle vcpu. The patch also adds an ASSERT to
> the same effect, in order to m
On Thu, 15 Dec 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 15/12/2016 01:04, Stefano Stabellini wrote:
> > The locking order is: first rank lock, then vgic lock. The order is
> > respected everywhere, except for gic_update_one_lr.
> >
> > gic_update_one_lr is called with the vgic lock held, bu
flight 103422 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103422/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 103284
Tests which
Create a basic Makefile to build and install libxenlight Golang
bindings. Also add a template.
---
Eventually this patch will contain the actual bindings package; for
now it just includes a stub package.
To Do:
- Have configure detect golang bindings properly
CC: xen-devel
CC: Ian Jackson
CC
On Thu, Dec 15, 2016 at 05:56:44PM -0500, Boris Ostrovsky wrote:
> With CONFIG_PARAVIRT (which I suspect you don't have on) cpuid() is a
> call via a pointer, you can see it, for example, if you disassemble
> load_ucode_amd_bsp(). And we don't have paging on yet when we call
> load_ucode_amd_bsp (a
Hi Stefano,
On 15/12/2016 01:04, Stefano Stabellini wrote:
The locking order is: first rank lock, then vgic lock. The order is
respected everywhere, except for gic_update_one_lr.
gic_update_one_lr is called with the vgic lock held, but it calls
vgic_get_target_vcpu, which tries to obtain the ra
On 12/15/2016 03:03 PM, Borislav Petkov wrote:
> On Thu, Dec 15, 2016 at 02:36:46PM -0500, Boris Ostrovsky wrote:
>> We are calling find_proper_container(..., &eq_id) and determine result
>> based on eq_id not being zero. If find_proper_container() doesn't find
>> anything it will not modify eq_id
On 15/12/2016 17:35, Bhupinder Thakur wrote:
Hi Julien,
Hi Bhupinder,
Thanks for the clarification. One more confirmation: When the reviewer
asks you to add the reviewed-by tag to one of the patch in the series
then also the whole series should be resent with just the reviewed-by
tag added
flight 103417 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103417/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 103284
Tests which
This run is configured for baseline tests only.
flight 68224 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68224/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 9 windows
On Thu, Dec 15, 2016 at 02:36:46PM -0500, Boris Ostrovsky wrote:
> We are calling find_proper_container(..., &eq_id) and determine result
> based on eq_id not being zero. If find_proper_container() doesn't find
> anything it will not modify eq_id and so you get back whatever you
> passed in.
The c
flight 103351 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103351/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 103163
test-armhf-armh
On 12/15/2016 02:23 PM, Borislav Petkov wrote:
> On Thu, Dec 15, 2016 at 02:08:50PM -0500, Boris Ostrovsky wrote:
>> This fixes my PV boot problem. I am still failing to boot HVM, will
>> need to look at this some more.
> No, no more stabbing in the dark and no more brown paper bags.
This fixes a
On Thu, Dec 15, 2016 at 02:08:50PM -0500, Boris Ostrovsky wrote:
> This fixes my PV boot problem. I am still failing to boot HVM, will
> need to look at this some more.
No, no more stabbing in the dark and no more brown paper bags.
Please check whether CPUID(4) works that early in any xen guest a
On 12/15/2016 12:36 PM, Borislav Petkov wrote:
> On Thu, Dec 15, 2016 at 12:27:49PM -0500, Boris Ostrovsky wrote:
>> It will probably fix it but I don't think we want this: it's a
>> build-time solution. Most kernels have XEN on even though they are
>> booted bare-metal.
> Lemme tell you want I wan
On Thu, 2016-12-08 at 11:38 +0100, Juergen Gross wrote:
> So you really solved the following problem in credit2?
>
> You have three domains with 2 vcpus each and different weights. Run
> them
> on 3 physical cpus with following pinning:
>
> dom1: pcpu 1 and 2
> dom2: pcpu 2 and 3
> dom3: pcpu 1 a
The patch gets rid of a redundant check in csched_vcpu_acct. In fact,
the function is only called from csched_tick, which already checks
that current is not the idle vcpu. The patch also adds an ASSERT to
the same effect, in order to make assumption ( i.e., no calling this
on idle vcpus) even more
On Fri, Dec 9, 2016 at 10:24 AM, Andy Lutomirski wrote:
> *** PATCHES 1 and 2 MAY BE 4.9 MATERIAL ***
>
> Alan Cox pointed out that the 486 isn't the only supported CPU that
> doesn't have CPUID. Let's clean up the mess and make everything
> faster while we're at it.
>
Ping? Any chance of getti
flight 103412 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103412/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 103284
Tests which
Hi Julien,
Thanks for the clarification. One more confirmation: When the reviewer
asks you to add the reviewed-by tag to one of the patch in the series
then also the whole series should be resent with just the reviewed-by
tag added to that single patch.
Regards,
Bhupinder
On 15 December 2016 at
On Thu, Dec 15, 2016 at 12:27:49PM -0500, Boris Ostrovsky wrote:
> It will probably fix it but I don't think we want this: it's a
> build-time solution. Most kernels have XEN on even though they are
> booted bare-metal.
Lemme tell you want I want: a way to detect I'm running on xen. Does
CPUID(4)
On 12/15/2016 12:17 PM, Borislav Petkov wrote:
> On Thu, Dec 15, 2016 at 12:00:22PM -0500, Boris Ostrovsky wrote:
>> There is an error on AMD as well. We end up being called at
>> load_microcode_amd() with size=0 and crash soon after.
> Does that fix it?
>
> diff --git a/arch/x86/Kconfig b/arch/x86
On 15/12/2016 17:14, Bhupinder Thakur wrote:
Hi Julien,
Hi Bhupinder,
I did not send the 1st patch in the series as there is no change in
the first patch since the last one I sent. I understood from your last
mail that I need not send the patch again if there is no change.
You misunderst
On Thu, Dec 15, 2016 at 12:00:22PM -0500, Boris Ostrovsky wrote:
> There is an error on AMD as well. We end up being called at
> load_microcode_amd() with size=0 and crash soon after.
Does that fix it?
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index dd47e60aabf5..e238119b5dff 100644
--- a/
On Thu, Dec 15, 2016 at 04:59:49PM +, Andrew Cooper wrote:
> Xen has the same logic as Linux does to look for an uncompressed
> microcode blob in the initrd and apply it early in boot.
>
> If dom0 goes looking, it should see the same microcode version as it has
> in its initrd.
So it sounds t
Hi Julien,
I did not send the 1st patch in the series as there is no change in
the first patch since the last one I sent. I understood from your last
mail that I need not send the patch again if there is no change.
Should I send it again after updating the version as 5? Should I add
the reviewed-
%ss, %fs and %gs can be calculated by directly masking the opcode. %es and
%ds cant, but the calculation isn't hard.
Use seg rather than dst.val for storing the calculated segment, which is
appropriately typed. Drop the sel local variable entirely and use dst.val
instead. The mode_64bit() check
On 15/12/16 17:46, Borislav Petkov wrote:
> On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote:
>> with today's kernel the system isn't coming up when booted as Xen dom0:
>
> Remind me again pls, is dom0 even supposed to load microcode? Isn't the
> hypervisor supposed to apply microcode
Hi,
The patch indicates "2/2" but I can't find the first patch. Is it a mistake?
Cheers,
On 15/12/2016 16:55, Bhupinder Thakur wrote:
VMID space is increased to 16-bits from 8-bits in ARMv8 8.1 revision.
This allows more than 256 VMs to be supported by Xen.
This change adds support for 16-bit
On 15/12/16 16:53, Jan Beulich wrote:
On 15.12.16 at 17:46, wrote:
>> On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote:
>>> with today's kernel the system isn't coming up when booted as Xen dom0:
>> Remind me again pls, is dom0 even supposed to load microcode? Isn't the
>> hyperv
VMID space is increased to 16-bits from 8-bits in ARMv8 8.1 revision.
This allows more than 256 VMs to be supported by Xen.
This change adds support for 16-bit VMIDs in Xen based on whether the
architecture supports it.
Signed-off-by: Bhupinder Thakur
---
xen/arch/arm/p2m.c | 52 ++
On 12/15/2016 11:46 AM, Borislav Petkov wrote:
> On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote:
>> with today's kernel the system isn't coming up when booted as Xen dom0:
> Remind me again pls, is dom0 even supposed to load microcode? Isn't the
> hypervisor supposed to apply microco
ok thank you very much
On Tuesday, December 13, 2016, Konrad Rzeszutek Wilk
wrote:
> On Tue, Dec 13, 2016 at 10:58:53AM +0530, George John wrote:
> > no, I meant some embedded platform like say for example minnowboard. Any
> > other boards like minnowboard?
>
> Based n
> https://ark.intel.com/p
>>> On 15.12.16 at 17:46, wrote:
> On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote:
>> with today's kernel the system isn't coming up when booted as Xen dom0:
>
> Remind me again pls, is dom0 even supposed to load microcode? Isn't the
> hypervisor supposed to apply microcode?
Yes,
>>> On 15.12.16 at 17:33, wrote:
> We're getting a FATAL TRAP when booting Xen 4.8 on 2 different servers (Xeon
> L5640 and Xeon L5520). The same xen binary boots fine on a third server with a
> Xeon E5-2650 v2 CPU, and the 3 servers boot fine when Xen is built with -01
> instead of -02 (gcc 4.9.2
On Thu, 15 Dec 2016, Boris Ostrovsky wrote:
> Since cpu hotplug callbacks are requested for CPUHP_AP_ONLINE_DYN state,
> successful callback initialization will result in cpuhp_setup_state()
> returning a positive value. Therefore acpi_cpufreq_online being zero
> indicates that callbacks have not
On 15/12/16 16:33, Vincent Legout wrote:
> Hello,
>
> We're getting a FATAL TRAP when booting Xen 4.8 on 2 different servers (Xeon
> L5640 and Xeon L5520). The same xen binary boots fine on a third server with a
> Xeon E5-2650 v2 CPU, and the 3 servers boot fine when Xen is built with -01
> instead
On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote:
> with today's kernel the system isn't coming up when booted as Xen dom0:
Remind me again pls, is dom0 even supposed to load microcode? Isn't the
hypervisor supposed to apply microcode?
> Looking into the state of cpu 1 I find the fol
>>> On 09.12.16 at 16:44, wrote:
> +/*
> + * DESIGN PRINCIPLES FOR THE SAFETY OF LIBELF
> + *
> + * libelf is a complex piece of code on a security boundary: when
> + * built as part of the tools, it parses guest kernels and loads them
> + * into guest memory. Bugs in libelf can become privilege
Hello,
We're getting a FATAL TRAP when booting Xen 4.8 on 2 different servers (Xeon
L5640 and Xeon L5520). The same xen binary boots fine on a third server with a
Xeon E5-2650 v2 CPU, and the 3 servers boot fine when Xen is built with -01
instead of -02 (gcc 4.9.2-10 from Debian jessie).
I've att
On Thu, Dec 15, 2016 at 9:53 AM, Ian Jackson wrote:
> I don't think "set max_pred_locks_per_transaction generously" is a
> practical thing to write in the documentation, because the application
> programmer, or admin, has no sensible way to calculate what a
> sufficiently generous value is.
ok
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan
> Beulich
> Sent: 15 December 2016 16:23
> To: Paul Durrant
> Cc: Andrew Cooper ; Daniel De Graaf
> ; Wei Liu ; Ian Jackson
> ; xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan
> Beulich
> Sent: 15 December 2016 16:06
> To: Paul Durrant
> Cc: Andrew Cooper ; Daniel De Graaf
> ; Wei Liu ; Ian Jackson
> ; xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 15 December 2016 15:45
> To: Paul Durrant
> Cc: Andrew Cooper ; Wei Liu
> ; George Dunlap ; Ian
> Jackson ; xen-de...@lists.xenproject.org; Daniel
> De Graaf ; Tim (Xen.org)
> Subject: Re: [PATCH v2 3/8] dm_op: co
>>> On 06.12.16 at 14:46, wrote:
> +struct xen_dm_op_inject_trap {
> +/* IN - index of vCPU */
> +uint32_t vcpuid;
> +/* IN - interrupt vector */
> +uint8_t vector;
> +/* IN - trap type (DMOP_TRAP_* ) */
> +uint8_t type;
> +/* NB. This enumeration precisely matches hvm.h:X8
On 12/12/16 19:05, Dejan Markic wrote:
> Hello all,
>
> sorry, as this might be a stupid question for some of you, but I
> wonder why here:
>
> https://github.com/mirage/xen/blob/master/tools/firmware/hvmloader/smbios.c#L438
>
>
> You allow almost everything to be overwritten in SMBIOS type 1 table
Hi George,
On 15/12/16 04:54, George Dunlap wrote:
On Wed, Dec 14, 2016 at 8:05 PM, Julien Grall wrote:
Note that ARM does not provide any hardware instruction to translate
an IPA (guest physical address) to a PA. So we have a walker there.
We also a walk for debugging guest page table (thoug
Boris,
with today's kernel the system isn't coming up when booted as Xen dom0:
[ 33.575326] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s!
[swapper/0:1]
[ 33.589795] Modules linked in:
[ 33.596015] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-pv+ #687
[ 33.608844] Hardware name:
>>> On 06.12.16 at 14:46, wrote:
> --- a/xen/arch/x86/hvm/dm.c
> +++ b/xen/arch/x86/hvm/dm.c
> @@ -199,6 +199,87 @@ static int modified_memory(struct domain *d, xen_pfn_t
> *first_pfn,
> return rc;
> }
>
> +static bool allow_p2m_type_change(p2m_type_t old, p2m_type_t new)
> +{
> +retu
>>> On 06.12.16 at 14:46, wrote:
> @@ -142,18 +143,77 @@ static int set_isa_irq_level(struct domain *d, uint8_t
> isa_irq,
> return 0;
> }
>
> +static int modified_memory(struct domain *d, xen_pfn_t *first_pfn,
> + unsigned int *nr)
> +{
> +xen_pfn_t last_pfn
On 15/12/16 15:53, Jan Beulich wrote:
> Commit 83cd2038fe ("VT-d: use msi_compose_msg()) together with
> 15aa6c6748 ("amd iommu: use base platform MSI implementation"),
> introducing the use of a per-CPU scratch CPU mask, went too far:
> dma_msi_set_affinity() may, at least in theory, be called in
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 15 December 2016 15:23
> To: Paul Durrant
> Cc: Andrew Cooper ; Ian Jackson
> ; Jennifer Herbert ;
> Wei Liu ; xen-de...@lists.xenproject.org; Daniel De
> Graaf
> Subject: Re: [PATCH v2 1/8] public / x86: Introduc
flight 103347 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103347/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf aaa61995af9e0b65c37bdad6796867760fa1d5fe
baseline version:
ovmf dc756baeda55490202f31
Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry
on constraint violation [and 2 more messages] [and 1 more messages]"):
> On Thu, Dec 15, 2016 at 6:09 AM, Ian Jackson
> wrote:
> > [...] Are there other reasons,
> > besides previously suppressed serialisation failur
Commit 83cd2038fe ("VT-d: use msi_compose_msg()) together with
15aa6c6748 ("amd iommu: use base platform MSI implementation"),
introducing the use of a per-CPU scratch CPU mask, went too far:
dma_msi_set_affinity() may, at least in theory, be called in
interrupt context, and hence the use of that s
On 06/12/16 11:25, Jan Beulich wrote:
> Their size parameters being "unsigned", there's neither a point for
> them returning "unsigned long", nor for any of their (assembly)
> arithmetic to involved 64-bit operations on other than addresses.
>
> Take the opportunity and fold __do_clear_user() into
>>> On 06.12.16 at 14:46, wrote:
> --- a/xen/include/public/hvm/dm_op.h
> +++ b/xen/include/public/hvm/dm_op.h
> @@ -191,6 +191,49 @@ struct xen_dm_op_track_dirty_vram {
> uint64_aligned_t first_pfn;
> };
>
> +/*
> + * XEN_DMOP_set_pci_intx_level: Set the logical level of one of a domain's
>>> On 06.12.16 at 14:46, wrote:
> @@ -68,6 +70,35 @@ static int
> copy_buf_to_guest(XEN_GUEST_HANDLE_PARAM(xen_dm_op_buf_t) bufs,
> return copy_to_guest(buf.h, src, size) ? -EFAULT : 0;
> }
>
> +static int track_dirty_vram(struct domain *d,
> +unsigned int nr_
flight 103406 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103406/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 103284
Tests which
On 15/12/16 14:16, Jan Beulich wrote:
On 15.12.16 at 13:52, wrote:
>> On 15/12/16 09:54, Jan Beulich wrote:
>> On 09.12.16 at 09:47, wrote:
>>> On 08.12.16 at 18:33, wrote:
> On 08/12/16 16:01, Jan Beulich wrote:
>> That commit ("VT-d: use msi_compose_msg()) together with 15
On 15/12/16 14:59, Jan Beulich wrote:
On 15.12.16 at 15:15, wrote:
>> On 09/12/16 08:59, Jan Beulich wrote:
>> On 08.12.16 at 18:51, wrote:
On 08/12/16 16:02, Jan Beulich wrote:
> variable. With an IRQ happening at the deepest point of the stack, and
> with send_guest_pirq()
>>> On 06.12.16 at 14:46, wrote:
> switch ( op.op )
> {
> +case XEN_DMOP_create_ioreq_server:
> +{
> +struct domain *curr_d = current->domain;
> +struct xen_dm_op_create_ioreq_server *data =
> +&op.u.create_ioreq_server;
> +
> +rc = -EINVAL;
>
>>> On 06.12.16 at 14:46, wrote:
> ...as a set of hypercalls to be used by a device model.
>
> As stated in the new docs/designs/dm_op.markdown:
>
> "The aim of DMOP is to prevent a compromised device model from
> compromising domains other then the one it is associated with. (And is
> therefore
flight 103339 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103339/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 5f54a923b496210af833b902afcc56b1982818a4
baseline version:
xtf 1f021c88130b4d2d818ba4
Ian Jackson writes ("Re: [xen-4.5-testing test] 103161: regressions - FAIL"):
> Andrew Cooper writes ("Re: [xen-4.5-testing test] 103161: regressions -
> FAIL"):
> > These leak check failures are because the XSA-195 PoC is somehow causing
> > qemu to segfault. I cant explain why, because qemu sho
>>> On 15.12.16 at 12:04, wrote:
> On 15/12/16 09:49, Jan Beulich wrote:
> On 06.12.16 at 11:51, wrote:
>>> As such clearing of flags may have an impact on the selected rendezvous
>>> function, handle such in a central place.
>>>
>>> But don't allow such feature flags to be cleared during CPU
Since cpu hotplug callbacks are requested for CPUHP_AP_ONLINE_DYN state,
successful callback initialization will result in cpuhp_setup_state()
returning a positive value. Therefore acpi_cpufreq_online being zero
indicates that callbacks have not been installed.
This means that acpi_cpufreq_boost_e
When ivoked with CPUHP_AP_ONLINE_DYN state __cpuhp_setup_state()
is expected to return positive value which is the hotplug state that
the routine assigns.
Signed-off-by: Boris Ostrovsky
---
kernel/cpu.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/kernel/cpu.c b
>>> On 15.12.16 at 13:03, wrote:
> On 15/12/16 09:57, Jan Beulich wrote:
> On 09.12.16 at 16:27, wrote:
>> On 09.12.16 at 16:19, wrote:
>>> On 09.12.16 at 15:56, wrote:
> It is a layering violation to remove the host_has_* part of the check
> from the emulator.
This is
>>> On 15.12.16 at 15:15, wrote:
> On 09/12/16 08:59, Jan Beulich wrote:
> On 08.12.16 at 18:51, wrote:
>>> On 08/12/16 16:02, Jan Beulich wrote:
variable. With an IRQ happening at the deepest point of the stack, and
with send_guest_pirq() being called from there (leading to vcpu_ki
The first patch corrects description of __cpuhp_setup_state()'s possible
return values and the second fixes a bug (which causes Xen guests to crash).
As a follow-up question for the first patch --- should we allow calling
__cpuhp_setup_state() with state in [CPUHP_AP_ONLINE_DYN + 1 ..
CPUHP_AP_ON
>>> On 15.12.16 at 13:52, wrote:
> On 15/12/16 09:54, Jan Beulich wrote:
> On 09.12.16 at 09:47, wrote:
>> On 08.12.16 at 18:33, wrote:
On 08/12/16 16:01, Jan Beulich wrote:
> That commit ("VT-d: use msi_compose_msg()) together with 15aa6c6748
Which commit?
>>> Oops - initi
On 09/12/16 08:59, Jan Beulich wrote:
On 08.12.16 at 18:51, wrote:
>> On 08/12/16 16:02, Jan Beulich wrote:
>>> variable. With an IRQ happening at the deepest point of the stack, and
>>> with send_guest_pirq() being called from there (leading to vcpu_kick()
>>> -> ... -> csched_vcpu_wake() ->
On 15/12/16 14:04, Jan Beulich wrote:
> Despite all attempts so far (ending in commit fecf584294 ["Config.mk:
> fix comment for debug option"] adjusting the respective comment),
> Config.mk's debug= setting still affects the hypervisor build: CFLAGS
> gets -g added there.
>
> xen/arch/x86/boot/buil
Despite all attempts so far (ending in commit fecf584294 ["Config.mk:
fix comment for debug option"] adjusting the respective comment),
Config.mk's debug= setting still affects the hypervisor build: CFLAGS
gets -g added there.
xen/arch/x86/boot/build32.mk includes that file, and hence inherits the
flight 103323 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103323/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm 11 guest-start fail REGR. vs. 103209
test-armhf-armh
On Thu, Dec 15, 2016 at 6:09 AM, Ian Jackson wrote:
> However, in that example, as you seem to allude to, there is still a
> complete serialisation of all the transactions, even the failed T3:
> T1,T2,T3. The database has detected the problem before returning data
> in T3 that would contradict t
On 14/12/16 21:18, Edgar E. Iglesias wrote:
On Wed, Dec 14, 2016 at 03:59:00PM +0100, Dario Faggioli wrote:
On Tue, 2016-12-13 at 19:00 +, Julien Grall wrote:
Hi all,
Stefano suggested to move the call at 5pm and I haven't seen any
disagreement.
So the call will be tomorrow (Wednesday 14t
flight 103401 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103401/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 103284
Tests which
1 - 100 of 156 matches
Mail list logo
