From: Quan Xu
If Device-TLB flush timed out, we hide the target ATS device
immediately. By hiding the device, we make sure it can't be
assigned to any domain any longer (see device_assigned).
Signed-off-by: Quan Xu
CC: Jan Beulich
CC: Kevin Tian
CC: Feng Wu
---
v13:
1. drop domain crash
From: Quan Xu
This patches fix current timeout concern and also allow limited ATS support.
these patches are the rest ones:
1. move the domain crash logic up to the generic IOMMU layer
2. If Device-TLB flush timed out, we hide the target ATS device
immediately. By hiding the device, we make
From: Quan Xu
Add domain crash logic to the generic IOMMU layer to benefit
all platforms.
No spamming of the log can occur. For DomU, we avoid logging any
message for already dying domains. For Dom0, that'll still be more
verbose than we'd really like, but it at least wouldn't outright
flood the
From: Quan Xu
A struct pci_dev* instead of SBDF is stored inside struct
pci_ats_dev and parameter to *_ats_device().
Also use ats_dev for "struct pci_ats_dev" variable, while
pdev (_pdev, if there is already a pdev) for "struct pci_dev"
in the scope of IOMMU.
Signed-off-by: Quan Xu
CC: Jan Be
On 28/06/16 20:06, David Vrabel wrote:
> /proc/xen/xenbus does not work correctly. A read blocked waiting for
> a xenstore message holds the mutex needed for atomic file position
> updates. This blocks any writes on the same file handle, which can
> deadlock if the write is needed to unblock the
> From: Lan, Tianyu
> Sent: Sunday, June 26, 2016 9:43 PM
>
> On 6/8/2016 4:11 PM, Tian, Kevin wrote:
> > It makes sense... I thought you used this security issue against
> > placing vIOMMU in Qemu, which made me a bit confused earlier. :-)
> >
> > We are still thinking feasibility of some staging
flight 96339 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96339/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 94748
test-amd64-amd64-
AVX-512 is an extention of AVX2. Its spec can be found at:
https://software.intel.com/sites/default/files/managed/b4/3a/319433-024.pdf
This patch detects AVX-512 features by CPUID.
Signed-off-by: Luwei Kang
---
xen/arch/x86/hvm/hvm.c | 14 ++
xen/arch/x86/traps.c
> From: Xu, Quan
> Sent: Sunday, June 26, 2016 6:33 PM
>
> On June 24, 2016 7:46 PM, Tian, Kevin wrote:
> > > From: Xu, Quan
> > > Sent: Friday, June 24, 2016 1:52 PM
> > >
> > > From: Quan Xu
> > >
> > > a struct pci_dev* instead of SBDF is stored inside struct pci_ats_dev
> > > and parameter t
> From: Tamas K Lengyel [mailto:ta...@tklengyel.com]
> Sent: Tuesday, June 28, 2016 2:08 AM
>
> Clean up the handling of TRAP_int3 VMEXITs to conform to the handling
> of TRAP_debug.
>
> Signed-off-by: Tamas K Lengyel
Acked-by: Kevin Tian
___
Xen-de
AVX-512 is an extention of AVX2. Its spec can be found at:
https://software.intel.com/sites/default/files/managed/b4/3a/319433-024.pdf
This patch detects AVX-512 features by CPUID.
Signed-off-by: Luwei Kang
---
xen/arch/x86/hvm/hvm.c | 14 ++
xen/arch/x86/traps.c
> From: Tamas K Lengyel [mailto:ta...@tklengyel.com]
> Sent: Tuesday, June 28, 2016 2:08 AM
>
> Since in-guest debug exceptions are now unconditionally trapped to Xen, adding
> a hook for vm_event subscribers to tap into this new always-on guest event. We
> rename along the way hvm_event_breakpoin
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, June 28, 2016 9:46 PM
>
> >>> On 28.06.16 at 10:12, wrote:
> > From: Kai Huang
> >
> > Below commit introduced a new macro MSR_IA32_FEATURE_CONTROL for
> > IA32_FEATURE_CONTROL MSR but it didn't remove old IA32_FEATURE_CONTROL_MSR
>
I'm trying to package Xen 4.6 (specifically Xen 4.6.3) for
use with NetBSD. I have it mostly done; however, when I try to
create a domU, libxl goes into an infinite loop calling the scripts.
If I try to create a domU with no network or disk, it works fine
(albeit of rather limited use). Have
(relo'd from user list)
I've launched an Ubuntu PVHVM guest, on a Xen 4.7 host
cat guest1.cfg
name = 'guest1'
builder = 'hvm'
xen_platform_pci = 1
device_model_version = 'qemu-xen'
bios = 'ovmf'
flight 96336 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96336/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt5 libvirt-build fail REGR. vs. 87893
build-amd64-libvi
flight 96349 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96349/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
On Tue, Jun 28, 2016 at 04:26:40PM -0700, elena.ufimts...@oracle.com wrote:
> From: Elena Ufimtseva
>
> Change gdbsx maintainer to myself.
>
>
> Signed-off-by: Elena Ufimtseva
Acked-by: Konrad Rzeszutek Wilk
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
From: Elena Ufimtseva
Change gdbsx maintainer to myself.
Signed-off-by: Elena Ufimtseva
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a8e0043..e91140f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -206,7 +206,7 @@ F: xen/c
flight 96335 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96335/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-build fail REGR. vs. 80927
build-i
On Mon, Jun 27, 2016 at 04:33:24PM +0800, Bob Liu wrote:
> Uncompleted reqs used to be 'saved and resubmitted' in blkfront_recover()
> during
> migration, but that's too later after multi-queue introduced.
>
> After a migrate to another host (which may not have multiqueue support), the
> number o
flight 96330 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96330/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 3 host-install(3) broken REGR. vs. 96296
build-armhf-xsm
On 28/06/16 18:56, Andrew Cooper wrote:
>
>
> This is the first in a number of changes trying to clean up error reporting of
> memory conditions.
One area which is constantly causing problems is creation of domains in
low memory conditions. In the case where the toolstack gets its
calculations w
On 28/06/16 17:17, Julien Grall wrote:
> Julien Grall (17):
> xen: Use typesafe gfn/mfn in guest_physmap_* helpers
> xen: Use typesafe gfn in xenmem_add_to_physmap_one
> xen/arm: Rename grant_table_gfpn into grant_table_gfn and use the
> typesafe gfn
Committed patches 1-3.
Thanks,
~And
On 28/06/16 11:18, Julien Grall wrote:
>
>> This is acceptable as the support of Xen for ARM64 in Linux has been
>> added
>> in Linux 3.11 and the number of boards supported by Linux 3.11 on
>> ARM64 is
>> very limited: ARM models and X-gene. And for the latter it was an early
>> support with only
simple_fill_super() will add symlinks if an entry has mode & S_IFLNK.
The target is provided in the new "link" field.
Signed-off-by: David Vrabel
---
v2:
- simplified.
---
fs/libfs.c | 15 +--
include/linux/fs.h | 2 +-
2 files changed, 14 insertions(+), 3 deletions(-)
diff
Using /proc/xen/xenbus can cause deadlocks on the atomic file position
mutex since this file should behave like a character device and not a
regular file. This is easiest to achive by making it a symlink to the
existing /dev/xen/xenbus device.
This requires extending simple_fill_super() to add sy
/proc/xen/xenbus does not work correctly. A read blocked waiting for
a xenstore message holds the mutex needed for atomic file position
updates. This blocks any writes on the same file handle, which can
deadlock if the write is needed to unblock the read.
/proc/xen/xenbus is supposed to be ident
On 28/06/16 18:56, Andrew Cooper wrote:
> assign_pages() has a return type of int, but uses for a boolean value. As
> there are two distinct failure cases, return a more meaningful error.
Sorry - sent an out of date version. This sentence actually reads
assign_pages() has a return type of int,
assign_pages() has a return type of int, but uses for a boolean value. As
there are two distinct failure cases, return a more meaningful error.
All caller currently use its boolean nature, so there is no resulting
change (yet).
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
On 28/06/16 17:47, Vitaly Kuznetsov wrote:
> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
> particular, when we crash on a secondary vCPU we may want to do kdump
> and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting
> on the vCPU which crashed. This doesn'
flight 96328 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96328/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR.
vs. 94856
test-amd64
On 28/06/16 17:47, Vitaly Kuznetsov wrote:
> @@ -1808,6 +1822,8 @@ static int xen_hvm_cpu_notify(struct notifier_block
> *self, unsigned long action,
> int cpu = (long)hcpu;
> switch (action) {
> case CPU_UP_PREPARE:
> + /* vLAPIC_ID == Xen's vCPU_ID * 2 for HVM guest
On 28/06/16 17:17, Julien Grall wrote:
> void guest_physmap_remove_page(struct domain *d,
> gfn_t gfn,
> mfn_t mfn, unsigned int page_order)
> {
> -apply_p2m_changes(d, REMOVE,
> - pfn_to_paddr(gfn_x(gfn)),
>
On 28/06/16 17:17, Julien Grall wrote:
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index f11094e..5ffc3df 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1211,20 +1211,20 @@ int unmap_mmio_regions(struct domain *d,
> }
>
> int map_dev_mmio_region(struct domain *d
On Tue, Jun 28, 2016 at 08:03:57AM -0600, Jan Beulich wrote:
> ld associates __init_end, placed outside of any section by the linker
> script, with the following section, resulting in a huge (wrapped, as it
> would be negative) section relative offset. COFF symbol tables store
> section relative ad
On 28/06/16 17:17, Julien Grall wrote:
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index a929e3b..b9ffce2 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -5298,7 +5298,7 @@ static int do_altp2m_op(
> a.u.enable_notify.vcpu_id != curr->vcp
On 28/06/16 17:17, Julien Grall wrote:
> @@ -60,16 +60,17 @@ dbg_hvm_va2mfn(dbgva_t vaddr, struct domain *dp, int
> toaddr,
> return INVALID_MFN;
> }
>
> -mfn = mfn_x(get_gfn(dp, *gfn, &gfntype));
> +mfn = get_gfn(dp, *gfn, &gfntype);
> if ( p2m_is_readonly(gfntype) &
On 28/06/16 17:47, Juergen Gross wrote:
On 28/06/16 18:43, Andrew Cooper wrote:
On 28/06/16 17:17, Julien Grall wrote:
A variable containing a guest frame should be compared to INVALID_GFN
and not INVALID_GFN.
I think the text should be changed? I'd expect one 'G' being replaced
bay 'M'. :-
On 28/06/16 17:52, Elena Ufimtseva wrote:
> Hi Julien, Andrew
>
> I was talking to Konrad some time ago about looking into this and the
> possibility of maintaining gdbsx code. I am willing sign up for this
> if there are no objections.
Fine by me. The traditional way of doing this would be for y
Hi Julien, Andrew
I was talking to Konrad some time ago about looking into this and the
possibility of maintaining gdbsx code. I am willing sign up for this
if there are no objections.
Elena
On Tue, Jun 28, 2016 at 9:46 AM, Andrew Cooper
wrote:
> On 28/06/16 17:31, Julien Grall wrote:
>> Hi,
>>
Ping!
Thanks,
Bhaktipriya
On Wed, Jun 1, 2016 at 9:15 PM, Tejun Heo wrote:
> On Wed, Jun 01, 2016 at 07:45:08PM +0530, Bhaktipriya Shridhar wrote:
>> System workqueues have been able to handle high level of concurrency
>> for a long time now and there's no reason to use dedicated workqueues
>> j
Ping!
Thanks,
Bhaktipriya
On Tue, May 31, 2016 at 10:59 PM, Tejun Heo wrote:
> On Tue, May 31, 2016 at 10:26:30PM +0530, Bhaktipriya Shridhar wrote:
>> System workqueues have been able to handle high level of concurrency
>> for a long time now and there's no reason to use dedicated workqueues
>>
shared_info page has space for 32 vcpu info slots for first 32 vCPUs but
these are the first 32 vCPUs from Xen's perspective and we should map them
accordingly with the newly introduced xen_vcpu_id mapping.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/xen/enlighten.c | 15 ++-
1 file
Historically we didn't call VCPUOP_register_vcpu_info for CPU0 for PVHVM
guests (while we had it for PV and ARM guests). This is usually fine as we
can use vcpu info in the sared_info page but when we try booting on a vCPU
with Xen's vCPU id > 31 (e.g. when we try to kdump after crashing on this
CP
Update cpuid.h header from xen hypervisor tree to get
XEN_HVM_CPUID_VCPU_ID_PRESENT definition.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/include/asm/xen/cpuid.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/xen/cpuid.h b/arch/x86/include/asm/xen
It may happen that Xen's and Linux's ideas of vCPU id diverge. In
particular, when we crash on a secondary vCPU we may want to do kdump
and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting
on the vCPU which crashed. This doesn't work very well for PVHVM guests as
we have a numb
EVTCHNOP_bind_ipi and EVTCHNOP_bind_virq pass vCPU id as a parameter and
Xen's idea of vCPU id should be used. Use the newly introduced xen_vcpu_id
mapping to convert it from Linux's id.
Signed-off-by: Vitaly Kuznetsov
---
drivers/xen/events/events_base.c | 10 +-
1 file changed, 5 inser
EVTCHNOP_init_control has vCPU id as a parameter and Xen's idea of vCPU id
should be used. Use the newly introduced xen_vcpu_id mapping to convert
it from Linux's id.
Signed-off-by: Vitaly Kuznetsov
---
drivers/xen/events/events_fifo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Use the newly introduced xen_vcpu_id mapping to get Xen's idea of vCPU id
for CPU0.
Signed-off-by: Vitaly Kuznetsov
---
drivers/xen/evtchn.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
index f4edd6df..0fc6be4 100644
--- a/driver
HYPERVISOR_vcpu_op passes Linux's idea of vCPU id as a parameter while
Xen's idea is expected. In some cases these ideas diverge so we need to
do remapping.
There is an issue, however. PV guests do VCPUOP_is_up very early
(see xen_fill_possible_map() and xen_filter_cpu_maps()) when we don't have
p
On 28/06/16 18:43, Andrew Cooper wrote:
> On 28/06/16 17:17, Julien Grall wrote:
>> A variable containing a guest frame should be compared to INVALID_GFN
>> and not INVALID_GFN.
I think the text should be changed? I'd expect one 'G' being replaced
bay 'M'. :-)
Juergen
>>
>> Signed-off-by: Julie
It may happen that Xen's and Linux's ideas of vCPU id diverge. In
particular, when we crash on a secondary vCPU we may want to do kdump
and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting
on the vCPU which crashed. This doesn't work very well for PVHVM guests as
we have a numb
On 28/06/16 17:31, Julien Grall wrote:
> Hi,
>
> I had to modify some code in arch/x86/debug.c and noticed that Mukesh
> is still the maintainer. IIRC he left Oracle quite a while ago, so my
> e-mail was bounced by the server.
>
> Do we have a new e-mail address for me? If not, does anyone plan to
On 28/06/16 17:17, Julien Grall wrote:
> A variable containing a guest frame should be compared to INVALID_GFN
> and not INVALID_GFN.
>
> Signed-off-by: Julien Grall
Reviewed-by: Andrew Cooper
I suspect these (mis)uses predate my movement of INVALID_GFN from x86
paging code to common code.
___
On 28/06/16 17:11, Jan Beulich wrote:
>>> --- a/xen/arch/x86/xen.lds.S
>>> +++ b/xen/arch/x86/xen.lds.S
>>> @@ -40,9 +40,20 @@ SECTIONS
>>> #if !defined(EFI)
>>>. = __XEN_VIRT_START;
>>>__image_base__ = .;
>>> +#else
>>> + . = __image_base__;
>>> #endif
>>>
>>> +#if 0
>>> +/*
>>> + * W
On 6/28/16 11:27 AM, Jan Beulich wrote:
On 28.06.16 at 15:59, wrote:
>> For xenstored running in the same domain as the toolstack, sockets are
>> less overhead than the shared memory ring, as no hypercalls are
>> involved. There is also the unfortunate problem that one of the two
>> linux de
Currently, accessing the I/O handlers does not require to take a lock
because new handlers are always added at the end of the array. In a
follow-up patch, this array will be sort to optimize the look up.
Given that most of the time the I/O handlers will not be modify,
using a spinlock will add con
Hi,
I had to modify some code in arch/x86/debug.c and noticed that Mukesh is
still the maintainer. IIRC he left Oracle quite a while ago, so my
e-mail was bounced by the server.
Do we have a new e-mail address for me? If not, does anyone plan to
maintain this code? Shall we mark the code as
>>> On 28.06.16 at 15:59, wrote:
> For xenstored running in the same domain as the toolstack, sockets are
> less overhead than the shared memory ring, as no hypercalls are
> involved. There is also the unfortunate problem that one of the two
> linux devices for xenstored *still* causes deadlocks
to avoid mixing machine frame with guest frame. Also drop the prefix start_.
Signed-off-by: Julien Grall
---
Changes in v4:
- Patch added
---
xen/arch/arm/mm.c | 2 +-
xen/arch/arm/p2m.c| 10 +-
xen/include/asm-arm/p2m.h | 4 ++--
3 files changed, 8 inserti
Signed-off-by: Julien Grall
---
Changes in v4:
- Patch added
---
xen/arch/arm/mm.c | 2 +-
xen/arch/arm/p2m.c| 18 +-
xen/include/asm-arm/p2m.h | 4 ++--
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/xen/arch/arm/mm.c b/xen/arch/ar
The prototype and the declaration of p2m_lookup disagree on how the
function should be used. One expect a frame number whilst the other
an address.
Thankfully, everyone is using with an address today. However, most of
the callers have to convert a guest frame to an address. Modify
the interface to
The operation ALLOCATE is unused. If we ever need it, it could be
reimplemented with INSERT.
Signed-off-by: Julien Grall
---
Changes in v4:
- Patch added
---
xen/arch/arm/p2m.c| 67 ++-
xen/include/asm-arm/p2m.h | 3 ---
2 files c
Also take the opportunity to convert arch/x86/debug.c to the typesafe
mfn.
Signed-off-by: Julien Grall
---
Cc: Christoph Egger
Cc: Liu Jinsong
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Mukesh Rathor
Cc: Paul Durrant
Cc: Jun Nakajima
Cc: Kevin Tian
Cc: George Dunlap
Cc: Tim Deegan
Chan
The code to allocate memory when dom0 does not use direct mapping is
relying on the presence of memory node in the DT.
However, they are not present when booting using UEFI or when using
ACPI.
Rather than fixing the code, remove it because dom0 is always direct
memory mapped and therefore the cod
A variable containing a guest frame should be compared to INVALID_GFN
and not INVALID_GFN.
Signed-off-by: Julien Grall
---
Cc: Suravee Suthikulpanit
Cc: Jan Beulich
Changes in v5:
- Patch added
---
xen/drivers/passthrough/amd/iommu_map.c | 2 +-
xen/drivers/passthrough/x86/iommu.
Also rename some variables to gfn or mfn when it does not require much
rework.
Finally replace %hu with %d when printing the domain id in
guest_physmap_add_entry (arch/x86/mm/p2m.c).
Signed-off-by: Julien Grall
Acked-by: Jan Beulich
Acked-by: Stefano Stabellini
---
Cc: Stefano Stabellini
Cc:
The correct acronym for a guest physical frame is gfn. Also use
the typesafe gfn to ensure that a guest frame is effectively used.
Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
---
Changes in v4:
- Add Stefano's acked-by
Changes in v2:
- Remove extra pair of
The x86 version of the function xenmem_add_to_physmap_one contains
variable name gpfn and gfn which make the code very confusing.
I have left unchanged for now.
Also, rename gpfn to gfn in the ARM version as the latter is the correct
acronym for a guest physical frame.
Finally, remove the trailin
Also take the opportunity to convert arch/x86/debug.c to the typesafe gfn.
Signed-off-by: Julien Grall
---
Cc: Mukesh Rathor
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Paul Durrant
Cc: Boris Ostrovsky
Cc: Suravee Suthikulpanit
Cc: Jun Nakajima
Cc: Kevin Tian
Cc: George Dunlap
Cc: Tim Deegan
More the half of the arguments of INSERT and REMOVE are the same for
each callers. Simplify the callers of apply_p2m_changes by adding new
helpers which will fill common arguments with default values.
Signed-off-by: Julien Grall
---
Changes in v5:
- Add missing Signed-off-by
Cha
The parameter 'access' is used by memaccess to restrict temporarily the
permission. This parameter should not be used for other purpose (such
as restricting permanently the permission).
The type p2m_mmio_direct will map the region Read-Write and
non-executable. Note that this is already the curren
to avoid mixing machine frame with guest frame.
Signed-off-by: Julien Grall
Acked-by: Jan Beulich
---
Cc: Stefano Stabellini
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Konrad Rzeszutek Wilk
Cc: Tim Deegan
Cc: Wei Liu
Changes in v3:
- Use mfn_add
Most of the callers of apply_p2m_changes have a GFN, a MFN and the
number of frame to change in hand.
Rather than asking each caller to convert the frame to an address,
rework the interfaces to pass the GFN, MFN and the number of frame.
Note that it would be possible to do more clean-up in apply_
to avoid mixing machine frame with guest frame. Also rename the
parameters of the function and drop pointless PAGE_MASK in the caller.
Signed-off-by: Julien Grall
---
Changes in v4:
- Patch added
---
xen/arch/arm/domain_build.c | 8
xen/arch/arm/p2m.c | 20 +++
p2m_cache_flush is expecting GFNs in parameter and not MFNs. Rename
the variable to *gfn* and use typesafe to avoid possible misusage.
Also, modify the prototype of the function to describe the range
using the start and the number of GFNs. This will avoid to wonder
whether the end if inclusive or
Hello all,
Some of the ARM functions are mixing gfn vs mfn and even physical vs frame.
To avoid more confusion, this patch series makes use of the terminology
described in xen/include/xen/mm.h and the associated typesafe.
This series requires the patch [1] to be applied beforehand. I pushed a
br
>>> On 28.06.16 at 16:26, wrote:
> On 28/06/16 15:03, Jan Beulich wrote:
>> ld associates __init_end, placed outside of any section by the linker
>> script, with the following section, resulting in a huge (wrapped, as it
>> would be negative) section relative offset.
>
> So in this case, the caus
The sorting was required by the vGIC emulation until commit
9b9d51e98edb8c5c731e2d06dfad3633053d88a4 "xen/arm: vgic-v3:
Correctly retrieve the vCPU associated to a re-distributor".
Furthermore, the code is buggy because both local variables 'l' and 'r'
point to the same region.
So drop the code w
flight 96333 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96333/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 6 xen-boot fail REGR. vs. 96299
Tests which did not succe
On 28/06/16 17:23, Andrew Cooper wrote:
> On 28/06/16 16:17, Doug Goldstein wrote:
>> On 6/28/16 8:59 AM, Andrew Cooper wrote:
>>> On 28/06/16 14:36, Juergen Gross wrote:
On 28/06/16 14:42, Andrew Cooper wrote:
> On 28/06/16 12:56, Juergen Gross wrote:
>> On 28/06/16 13:03, Ian Jackson
On 28/06/16 16:17, Doug Goldstein wrote:
> On 6/28/16 8:59 AM, Andrew Cooper wrote:
>> On 28/06/16 14:36, Juergen Gross wrote:
>>> On 28/06/16 14:42, Andrew Cooper wrote:
On 28/06/16 12:56, Juergen Gross wrote:
> On 28/06/16 13:03, Ian Jackson wrote:
>> Juergen Gross writes ("Re: [Xen-
On 6/28/16 8:59 AM, Andrew Cooper wrote:
> On 28/06/16 14:36, Juergen Gross wrote:
>> On 28/06/16 14:42, Andrew Cooper wrote:
>>> On 28/06/16 12:56, Juergen Gross wrote:
On 28/06/16 13:03, Ian Jackson wrote:
> Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy
> config
On 28/06/16 15:58, Juergen Gross wrote:
> On 28/06/16 15:59, Andrew Cooper wrote:
>> On 28/06/16 14:36, Juergen Gross wrote:
>>> On 28/06/16 14:42, Andrew Cooper wrote:
On 28/06/16 12:56, Juergen Gross wrote:
> On 28/06/16 13:03, Ian Jackson wrote:
>> Juergen Gross writes ("Re: [Xen-de
On 28/06/16 15:59, Andrew Cooper wrote:
> On 28/06/16 14:36, Juergen Gross wrote:
>> On 28/06/16 14:42, Andrew Cooper wrote:
>>> On 28/06/16 12:56, Juergen Gross wrote:
On 28/06/16 13:03, Ian Jackson wrote:
> Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy
> configu
On 06/28/2016 08:51 AM, Shanker Donthineni wrote:
Hi Julien,
On 06/28/2016 05:40 AM, Julien Grall wrote:
Hello Shanker,
On 27/06/16 21:33, Shanker Donthineni wrote:
@@ -1397,6 +1408,36 @@ gic_acpi_parse_madt_distributor(struct
acpi_subtable_header *header,
}
static int __init
+gic_a
On 28/06/16 15:03, Jan Beulich wrote:
> ld associates __init_end, placed outside of any section by the linker
> script, with the following section, resulting in a huge (wrapped, as it
> would be negative) section relative offset.
So in this case, the cause of the truncation is due to __init_end be
ld associates __init_end, placed outside of any section by the linker
script, with the following section, resulting in a huge (wrapped, as it
would be negative) section relative offset. COFF symbol tables store
section relative addresses, and hence the above leads to assembler
truncation warnings w
On 28/06/16 14:36, Juergen Gross wrote:
> On 28/06/16 14:42, Andrew Cooper wrote:
>> On 28/06/16 12:56, Juergen Gross wrote:
>>> On 28/06/16 13:03, Ian Jackson wrote:
Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy
configurable"):
> So you are telling me the xensto
On 28/06/16 14:52, Juergen Gross wrote:
> On 28/06/16 14:42, Andrew Cooper wrote:
>> On 28/06/16 12:56, Juergen Gross wrote:
>>> On 28/06/16 13:03, Ian Jackson wrote:
Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy
configurable"):
> So you are telling me the xensto
Hi Julien,
On 06/28/2016 05:40 AM, Julien Grall wrote:
Hello Shanker,
On 27/06/16 21:33, Shanker Donthineni wrote:
@@ -1397,6 +1408,36 @@ gic_acpi_parse_madt_distributor(struct
acpi_subtable_header *header,
}
static int __init
+gic_acpi_parse_cpu_redistributor(struct acpi_subtable_head
On 28/06/16 14:42, Andrew Cooper wrote:
> On 28/06/16 12:56, Juergen Gross wrote:
>> On 28/06/16 13:03, Ian Jackson wrote:
>>> Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy
>>> configurable"):
So you are telling me the xenstore domain won't work for this case?
>>> Yes.
>>
>>> On 28.06.16 at 10:12, wrote:
> From: Kai Huang
>
> Below commit introduced a new macro MSR_IA32_FEATURE_CONTROL for
> IA32_FEATURE_CONTROL MSR but it didn't remove old IA32_FEATURE_CONTROL_MSR
> macro. The new one has better naming convention, so remove the old as a
> duplication. Also move
On 06/28/2016 07:03 AM, Shannon Zhao wrote:
>
> On 2016/6/27 20:05, Boris Ostrovsky wrote:
>>
>> On 06/27/2016 06:29 AM, Julien Grall wrote:
>>> (CC Boris and Doug)
>>>
>>> Hi Shannon,
>>>
>>> On 27/06/16 07:01, Shannon Zhao wrote:
On 2016/6/24 1:03, Julien Grall wrote:
> On 23/06/16 04:16
On 28/06/16 14:42, Andrew Cooper wrote:
> On 28/06/16 12:56, Juergen Gross wrote:
>> On 28/06/16 13:03, Ian Jackson wrote:
>>> Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy
>>> configurable"):
So you are telling me the xenstore domain won't work for this case?
>>> Yes.
>>
>>> On 28.06.16 at 13:23, wrote:
> A clue on doing this would be useful, I can't debug what is now release
> code all day.
Well, debugging (released code or not) is what's needed, I'm afraid.
A first step would be to find out how far the corruption extends:
Considering the non-zero code bytes tha
On 28/06/16 14:19, Shanker Donthineni wrote:
On 06/28/2016 05:49 AM, Julien Grall wrote:
On 27/06/16 21:33, Shanker Donthineni wrote:
As the number of I/O handlers increase, the overhead associated with
linear lookup also increases. The system might have maximum of 144
(assuming CONFIG_NR_CPU
Hi Julien,
On 06/28/2016 05:49 AM, Julien Grall wrote:
Hi Shanker,
On 27/06/16 21:33, Shanker Donthineni wrote:
As the number of I/O handlers increase, the overhead associated with
linear lookup also increases. The system might have maximum of 144
(assuming CONFIG_NR_CPUS=128) mmio handlers.
On 28/06/16 12:56, Juergen Gross wrote:
> On 28/06/16 13:03, Ian Jackson wrote:
>> Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy
>> configurable"):
>>> So you are telling me the xenstore domain won't work for this case?
>> Yes.
> That's rather unfortunate. So in order to be ab
1 - 100 of 146 matches
Mail list logo
