flight 112597 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112597/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 7 reboot fail REGR. vs. 110515
test-amd64-amd64-xl
flight 112601 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112601/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf cc993a16e40372c07a0507d02d1030546470f986
baseline version:
ovmf bee7fe0ef950e2966cbdc
flight 112599 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112599/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR.
vs. 112513
test-amd6
flight 112598 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112598/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs.
112557
test-amd64-
This run is configured for baseline tests only.
flight 71966 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71966/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf bee7fe0ef950e2966cbdcd753be326f8a3c782f3
baseline v
flight 112595 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112595/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 3 capture-logs broken REGR. vs. 112102
On 07/31/2017 06:57 PM, Stefano Stabellini wrote:
> Implement the probe function for the pvcalls frontend. Read the
> supported versions, max-page-order and function-calls nodes from
> xenstore.
>
> Only one frontend<->backend connection is supported at any given time
> for a guest. Store the activ
flight 112593 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112593/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 112551
test-amd64-i386-qemu
On 07/31/2017 06:57 PM, Stefano Stabellini wrote:
> Introduce a data structure named pvcalls_bedata. It contains pointers to
> the command ring, the event channel, a list of active sockets and a list
> of passive sockets. Lists accesses are protected by a spin_lock.
>
> Introduce a waitqueue to all
On 08/11/2017 02:27 PM, Wei Liu wrote:
On Fri, Aug 11, 2017 at 12:37:04PM -0600, Jim Fehlig wrote:
On 08/11/2017 05:45 AM, Wei Liu wrote:
On Thu, Aug 10, 2017 at 03:42:24PM -0600, Jim Fehlig wrote:
On 08/08/2017 09:09 AM, Wei Liu wrote:
Ian and Stefano
Oleksandr discovered that the p9fs arra
On 07/31/2017 06:57 PM, Stefano Stabellini wrote:
> Introduce a xenbus frontend for the pvcalls protocol, as defined by
> https://xenbits.xen.org/docs/unstable/misc/pvcalls.html.
>
> This patch only adds the stubs, the code will be added by the following
> patches.
>
> Signed-off-by: Stefano Stabel
On Fri, Aug 11, 2017 at 12:37:04PM -0600, Jim Fehlig wrote:
> On 08/11/2017 05:45 AM, Wei Liu wrote:
> > On Thu, Aug 10, 2017 at 03:42:24PM -0600, Jim Fehlig wrote:
> > > On 08/08/2017 09:09 AM, Wei Liu wrote:
> > > > Ian and Stefano
> > > >
> > > > Oleksandr discovered that the p9fs array in libx
On 08/11/2017 05:45 AM, Wei Liu wrote:
On Thu, Aug 10, 2017 at 03:42:24PM -0600, Jim Fehlig wrote:
On 08/08/2017 09:09 AM, Wei Liu wrote:
Ian and Stefano
Oleksandr discovered that the p9fs array in libxl_domain_config is name
p9 instead of p9s. This causes problem for his work to rework device
This is a left over of before the P2M code was reworked. So drop it.
Signed-off-by: Julien Grall
---
xen/arch/arm/p2m.c | 4
1 file changed, 4 deletions(-)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 7b2aac4c90..c484469e6c 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p
Hi,
Please ignore this thread, I forgot to remove the *.patch in the folder
before sending another series :/
Sorry for the noise.
On 11/08/17 19:11, Julien Grall wrote:
Hi all,
xen/arch/arm/traps.c is beginning to get very big. This series is moving out
the co-processor and sysreg emulate i
This is a left over of before the P2M code was reworked. So drop it.
Signed-off-by: Julien Grall
---
xen/arch/arm/p2m.c | 4
1 file changed, 4 deletions(-)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 7b2aac4c90..c484469e6c 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p
Hi all,
xen/arch/arm/traps.c is beginning to get very big. This series is moving out
the co-processor and sysreg emulate in separate files. This will avoid to grow
traps.c when adding more registers emulations (coming soon).
A branch with this series has been pushed:
https://xenbits.xen.org/git-
On Wed, Aug 09, 2017 at 04:51:21PM -0400, Lan Tianyu wrote:
> From: Chao Gao
>
> If a vIOMMU is exposed to guest, guest will configure the msi to remapping
> format. The original code isn't suitable to the new format. A new pair
> bind/unbind interfaces are added for this usage. This patch recogn
Signed-off-by: Julien Grall
---
xen/arch/arm/vgic-v3.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 48c7682671..cbeac28b28 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -19,16 +19,17 @@
*/
It will be necessary to include vtimer.h from subdirectory making the
inclusion a bit awkward.
Signed-off-by: Julien Grall
---
xen/arch/arm/domain.c | 2 +-
xen/arch/arm/traps.c | 2 +-
xen/{arch/arm => include/asm-arm}/vtimer.h | 0
3 files changed, 2
The co-processor emulation is quite big and pretty much standalone. Move
it in a separate file to shrink down the size of traps.c.
At the same time remove unused cpregs.h.
No functional change.
Signed-off-by: Julien Grall
---
xen/arch/arm/Makefile | 1 +
xen/arch/arm/traps.c| 4
A follow-up patch will move some parts of traps.c in separate files.
The will require to use helpers that are currently statically defined.
Export the following helpers:
- inject_undef64_exception
- inject_undef_exception
- check_conditional_instr
- advance_pc
- handle_raz_wi
Signed-off-by: Julien Grall
---
xen/arch/arm/traps.c | 42 ++
1 file changed, 22 insertions(+), 20 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index c07999b518..ca9bef712c 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps
Hi all,
xen/arch/arm/traps.c is beginning to get very big. This series is moving out
the co-processor and sysreg emulate in separate files. This will avoid to grow
traps.c when adding more registers emulations (coming soon).
A branch with this series has been pushed:
https://xenbits.xen.org/git-
The sysreg emulation is 64-bit specific and surrounded by #ifdef. Move
them in a separate file arm/arm64/vsysreg.c to shrink down a bit traps.c
No functional change.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm64/Makefile | 1 +
xen/arch/arm/arm64/vsysreg.c | 229 ++
While re-ordering the include alphabetically in arch/arm/domain.c, I got
a complitation error because grant_table.h is using gfn_t before been
defined:
In file included from domain.c:14:0:
xen/xen/include/xen/grant_table.h:153:29: error: unknown type name ‘gfn_t’
gfn_t
Signed-off-by: Julien Grall
---
xen/arch/arm/vtimer.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index 32ac1279ae..9c7e8f441c 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -18,16 +18,17 @@
*/
Currently, cpregs.h is included in pretty much every files even for
arm64. However, the only use for arm64 is when emulating co-processors.
For arm32, cpregs.h rely on the presence of processor.h (define
*_SYSREG helpers). So move the inclusion in asm-arm/arm32/processor.h.
cpregs.h will also be
Signed-off-by: Julien Grall
---
xen/arch/arm/domain.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 2dc8b0ab5a..1d835d321d 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -9,6 +9,9
sysregs.h contains only code protected by #ifdef CONFIG_ARM_64. Move it
in arm64 sub-directory to reflect that and remove the #ifdef.
At the same time, fixup the guards.
Signed-off-by: Julien Grall
---
xen/include/asm-arm/arm64/processor.h | 2 ++
xen/include/asm-arm/{ => arm64}/sysregs.h
flight 112594 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112594/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf bee7fe0ef950e2966cbdcd753be326f8a3c782f3
baseline version:
ovmf f8daac8121e66c46d3374
On Wed, 2017-08-09 at 12:38 +0100, Tim Deegan wrote:
> Hi,
>
Hey! :-)
> At 10:01 +0200 on 27 Jul (1501149684), Dario Faggioli wrote:
> > In Xen, that is impossible, and that's particularly problematic
> > when system is idle (or lightly loaded) systems, as CPUs that
> > are idle may never have th
flight 112588 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112588/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs.
112544
Tests which
On Fri, Aug 11, 2017 at 04:11:37PM +0100, Anthony PERARD wrote:
> To do PCI passthrough with Xen, the property acpi-pcihp-bsel needs to be
> set, but this was done only when ACPI tables are built which is not
> needed for a Xen guest. The need for the property starts with commit
> "pc: pcihp: avoid
On Fri, 11 Aug 2017, Wei Liu wrote:
> On Thu, Aug 10, 2017 at 03:42:24PM -0600, Jim Fehlig wrote:
> > On 08/08/2017 09:09 AM, Wei Liu wrote:
> > > Ian and Stefano
> > >
> > > Oleksandr discovered that the p9fs array in libxl_domain_config is name
> > > p9 instead of p9s. This causes problem for hi
From: Manish Jaggi
This patch extends the gicv3_iomem_deny_access functionality by adding support
for its region as well. Added function gicv3_its_deny_access.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/gic-v3-its.c| 19 +++
xen/arch/arm/gic-v3.c| 7 +
From: Manish Jaggi
estimate_acpi_efi_size needs to be updated to provide correct size of
hardware domains MADT, which now adds ITS information as well.
Introducing gic_get_hwdom_madt_size.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/domain_build.c | 7 +--
xen/arch/arm/gic-v2.c
From: Manish Jaggi
Added gicv3_its_acpi_init to update host_its_list from MADT table.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/gic-v3-its.c| 14 ++
xen/arch/arm/gic-v3.c| 8
xen/include/asm-arm/gic_v3_its.h | 13 +
3 files changed, 35 i
From: Manish Jaggi
Adds gicv3_its_make_hwdom_madt to update hwdom MADT ITS information.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/gic-v3-its.c| 24
xen/arch/arm/gic-v3.c| 1 +
xen/include/asm-arm/gic_v3_its.h | 1 +
3 files changed, 26 insertio
From: Manish Jaggi
add_to_host_its_list will update the host_its_list. This common function to
be invoked from gicv3_its_dt_init and gic_v3_its_acpi_init.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/gic-v3-its.c | 36 +++-
1 file changed, 23 insertions(+), 13 d
From: Manish Jaggi
This patch is split into 5 patches. First two add support for updating
host_its_list from ACPI MADT table.
The rest patches provide support to update the hardware domain MADT table
with ITS information.
Changes since v1:
- split patches into smaller ones
- removed translation_
On certain Intel systems, as far as I can tell almost all pre-Haswell ones,
trying to boot a PVH Dom0 will freeze the box completely, up to the point that
not even the watchdog works. The freeze happens exactly when enabling the DMA
remapping in the IOMMU, the last line seen is:
(XEN) [VT-D]iommu_
They are emulated by Xen, so they must not be mapped into Dom0 p2m.
Introduce a helper function to add the MMCFG areas to the list of
denied iomem regions for PVH Dom0.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since RFC:
- Introduce as helper instead of
This is emulated by Xen and must not be mapped into PVH Dom0 p2m.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/dom0_build.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 3
Make sure the reserved regions are setup before enabling the DMA
remapping in the IOMMU, by calling dom0_setup_permissions before
iommu_hwdom_init. Also, in order to workaround IOMMU issues seen on
pre-Haswell Intel hardware, as described in patch "introduce a PVH
implementation of iommu_inclusive_
Hello,
Currently iommu_inclusive_mapping is not working for PVH Dom0, this patch
series allows using it for a PVH Dom0, which seems to be required in order to
boot on older boxes.
Git branch can be found at:
git://xenbits.xen.org/people/royger/xen.git iommu_inclusive_v2
Thanks, Roger.
This commit makes the changes to the hypervisor, the build system as
well as libxc necessary in order to facilitate tracing of program counters.
A discussion of the design can be found in the mailing list:
https://lists.xen.org/archives/html/xen-devel/2017-05/threads.html#02210
The list of files
Adding PCI passthrough before the guest start works fine (broken in 2.9 but now
fixed), but hotplug does not work anymore.
Anthony PERARD (2):
hw/acpi: Call acpi_set_pci_info when no ACPI tables needed
Revert "ACPI: don't call acpi_pcihp_device_plug_cb on xen"
hw/acpi/piix4.c | 11 +++--
This reverts commit 153eba4726dfa1bdfc31d1fe973b2a61b9035492.
This patch prevents PCI passthrough hotplug on Xen. Even if the Xen tool
stack prepares its own ACPI tables, we still rely on QEMU for hotplug
ACPI notifications.
The original issue is fixed by the previous patch (hw/acpi: Call
acpi_se
To do PCI passthrough with Xen, the property acpi-pcihp-bsel needs to be
set, but this was done only when ACPI tables are built which is not
needed for a Xen guest. The need for the property starts with commit
"pc: pcihp: avoid adding ACPI_PCIHP_PROP_BSEL twice"
(f0c9d64a68b776374ec4732424a3e27753c
On Fri, Aug 11, 2017 at 5:41 AM, Ingo Molnar wrote:
>
> * Thomas Garnier wrote:
>
>> Changes:
>> - v2:
>>- Add support for global stack cookie while compiler default to fs without
>> mcmodel=kernel
>>- Change patch 7 to correctly jump out of the identity mapping on kexec
>> load
>>
On Fri, Aug 11, 2017 at 5:36 AM, Pavel Machek wrote:
> On Thu 2017-08-10 10:26:05, Thomas Garnier wrote:
>> Change the assembly code to use only relative references of symbols for the
>> kernel to be PIE compatible.
>>
>> Position Independent Executable (PIE) support will allow to extended the
>>
When running as Xen pv-guest the exception frame on the stack contains
%r11 and %rcx additional to the other data pushed by the processor.
Instead of having a paravirt op being called for each exception type
prepend the Xen specific code to each exception entry. When running as
Xen pv-guest just u
On 29/07/17 18:59, Liu Shuo wrote:
> Here is a device has xen-pirq-MSI interrupt. Dom0 might lost interrupt
> during driver irq_disable/irq_enable. Here is the scenario,
> 1. irq_disable -> disable_dynirq -> mask_evtchn(irq channel)
> 2. dev interrupt raised by HW and Xen mark its evtchn as pendi
This patch adjusts the IOREQ server code to use type-safe gfn_t values
where possible. No functional change.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: Jan Beulich
---
xen/arch/x86/hvm/ioreq.c | 42
xen/include/asm-x86/hvm/domain.h |
... XENMEM_resource_ioreq_server
This patch adds support for a new resource type that can be mapped using
the XENMEM_acquire_resource memory op.
If an emulator makes use of this resource type then, instead of mapping
gfns, the IOREQ server will allocate pages from the heap. These pages
will never
A subsequent patch will introduce a new scheme to allow an emulator to
map IOREQ server pages directly from Xen rather than the guest P2M.
This patch lays the groundwork for that change by deferring mapping of
gfns until their values are requested by an emulator. To that end, the
pad field of the
Hi Andre,
On 21/07/17 20:59, Andre Przywara wrote:
As the priority value is now officially a member of struct pending_irq,
we need to take its lock when manipulating it via ITS commands.
Make sure we take the IRQ lock after the VCPU lock when we need both.
Signed-off-by: Andre Przywara
---
xe
Hi Andre,
On 21/07/17 20:59, Andre Przywara wrote:
So far a virtual interrupt's priority is stored in the irq_rank
structure, which covers multiple IRQs and has a single lock for this
group.
Generalize the already existing priority variable in struct pending_irq
to not only cover LPIs, but every
In the case where a PV domain is mapping guest resources then it needs make
the HYPERVISOR_mmu_update call using DOMID_SELF, rather than the guest
domid, so that the passed in gmfn values are correctly treated as mfns
rather than gfns present in the guest p2m.
This patch removes a check which curr
This patch re-works much of the IOREQ server initialization and teardown
code:
- The hvm_map/unmap_ioreq_gfn() functions are expanded to call through
to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called
separately by outer functions.
- Several functions now test the validity o
Certain memory resources associated with a guest are not necessarily
present in the guest P2M and so are not necessarily available to be
foreign-mapped by a tools domain unless they are inserted, which risks
shattering a super-page mapping.
This patch adds a new memory op to allow such resourced t
A previous patch introduced a new HYPERVISOR_memory_op to acquire guest
resources for direct priv-mapping.
This patch adds new functionality into libxenforeignmemory to make use
of a new privcmd ioctl [1] that uses the new memory op to make such
resources available via mmap(2).
[1]
http://xenbit
A previous patch added support for priv-mapping guest resources directly
(rather than having to foreign-map, which requires P2M modification for
HVM guests).
This patch makes use of the new API to seed the guest grant table unless
the underlying infrastructure (i.e. privcmd) doesn't support it, in
This series introduces support for direct mapping of guest resources.
The resources are:
- Grant tables
- IOREQ server pages
Paul Durrant (12):
[x86|arm]: remove code duplication
x86/mm: allow a privileged PV domain to map guest mfns
x86/mm: add HYPERVISOR_memory_op to acquire guest resour
There is a substantial amount of code duplicated between the x86 and arm
implementations of mm.c:xenmem_add_to_physmap_one() for
XENMAPSPACE_grant_table. Also, the code in question looks like it really
should be in common/grant_table.c
This patch introduces a new function in common/grant_table.c t
This patch changes use of bool_t to bool in the IOREQ server code. It also
fixes an incorrect indentation in a continuation line.
This patch is purely cosmetic. No semantic or functional change.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/dm.c
Legacy emulators use the 'default' IOREQ server which has slightly
different semantics than other, explicitly created, IOREQ servers.
Because of this, most of the initialization and teardown code needs to
know whether the server is default or not. This is currently achieved
by passing an is_defaul
Since IOREQ servers are only relevant to HVM guests and all the names in
question unequivocally refer to guest frame numbers, name them all .*gfn
to avoid any confusion.
This patch is purely cosmetic. No semantic or functional change.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew C
Hi Andre,
On 21/07/17 20:59, Andre Przywara wrote:
Since the GICs MMIO access always covers a number of IRQs at once,
introduce wrapper functions which loop over those IRQs, take their
locks and read or update the priority values.
This will be used in a later patch.
Signed-off-by: Andre Przywar
Hello All,
Is there any way in linux e.g using device tree, to give a driver a fixed
physical memory range to alloc pages from? All pages are allocated from kernel
memory assigned using memory node in device tree. Is there any way to create a
memory node and assign it to driver so that buddy a
flight 112596 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112596/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-pvops 2 hos
On 11/08/17 14:26, Volodymyr Babchuk wrote:
On 10.08.17 00:22, Julien Grall wrote:
On 09/08/2017 22:06, Volodymyr Babchuk wrote:
Hi Julien,
On 09.08.17 23:34, Julien Grall wrote:
On 09/08/2017 20:44, Volodymyr Babchuk wrote:
On ARMv8, one of conditional exceptions (SMC that originate
On Fri, Aug 11, 2017 at 03:07:29PM +0200, Juergen Gross wrote:
> On 11/08/17 14:54, Peter Zijlstra wrote:
> > On Fri, Aug 11, 2017 at 02:46:41PM +0200, Juergen Gross wrote:
> >> Aah, okay. Now I understand the problem. The TLB isn't the issue but the
> >> IPI is serving two purposes here: TLB flush
The hypercall argument translation area lives in the per-domain mappings in
PML4 slot 260. Nothing currently resides in the lower canonical half above
the 4GB boundary in a 32bit PV guest.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/include/asm-x86/config.h | 8 ++--
1 file ch
On 10.08.17 00:22, Julien Grall wrote:
On 09/08/2017 22:06, Volodymyr Babchuk wrote:
Hi Julien,
On 09.08.17 23:34, Julien Grall wrote:
On 09/08/2017 20:44, Volodymyr Babchuk wrote:
On ARMv8, one of conditional exceptions (SMC that originates
from aarch32 state) have extra field in HCR.I
This in turn calls for p2m_alloc_ptp() also being passed the numeric
level.
Signed-off-by: Jan Beulich
Reviewed-by: George Dunlap
---
v2: New.
---
Question is whether passing the level to p2m_alloc_ptp() is really all
that useful: p2m-ept.c's passes zero only anyway, and p2m.c's uniform
passing
flight 112581 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112581/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail REGR. vs.
112557
Regressions
None of the callers really needs the struct page_info pointer.
Signed-off-by: Jan Beulich
Acked-by: George Dunlap
---
v3: Re-base over changes to patch 1.
v2: Re-base over changes to patch 1.
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -569,7 +569,7 @@ int p2m_set_entry(struct p2
Calculate entry PFN and flags just once. Convert the two successive
main if()-s to and if/else-if chain. Restrict variable scope where
reasonable. Take the opportunity and also make the induction variable
unsigned.
This at once fixes excessive permissions granted in the 2M PTEs
resulting from spli
1: simplify p2m_next_level()
2: make p2m_alloc_ptp() return an MFN
3: pass level instead of page type to p2m_next_level()
Signed-off-by: Jan Beulich
See individual patches for change info.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://li
Reported-by: Julien Grall
Signed-off-by: Jan Beulich
---
v2: Comment the pl2e related ASSERT().
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5903,7 +5903,7 @@ int modify_xen_mappings(unsigned long s,
{
l3_pgentry_t *pl3e = virt_to_xen_l3e(v);
-if ( !(l3e_get_flags(
Hi Julien,
On 11.08.17 00:09, Julien Grall wrote:
On 10/08/2017 21:09, Volodymyr Babchuk wrote:
Hi,
On 10.08.17 21:18, Julien Grall wrote:
Hi,
On 10/08/17 18:40, Volodymyr Babchuk wrote:
On 10.08.17 19:11, Julien Grall wrote:
On 10/08/17 16:33, Volodymyr Babchuk wrote:
Hi Julien,
O
>>> On 27.07.17 at 18:50, wrote:
> On Wed, Jul 5, 2017 at 11:06 AM, Jan Beulich wrote:
>> This in turn calls for p2m_alloc_ptp() also being passed the numeric
>> level.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> v2: New.
>> ---
>> Question is whether passing the level to p2m_alloc_ptp() is reall
On 11/08/17 14:54, Peter Zijlstra wrote:
> On Fri, Aug 11, 2017 at 02:46:41PM +0200, Juergen Gross wrote:
>> Aah, okay. Now I understand the problem. The TLB isn't the issue but the
>> IPI is serving two purposes here: TLB flushing (which is allowed to
>> happen at any time) and serialization regar
This run is configured for baseline tests only.
flight 71963 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71963/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f8daac8121e66c46d3374f63f80308a777c2a2e7
baseline v
On Fri, Aug 11, 2017 at 02:46:41PM +0200, Juergen Gross wrote:
> Aah, okay. Now I understand the problem. The TLB isn't the issue but the
> IPI is serving two purposes here: TLB flushing (which is allowed to
> happen at any time) and serialization regarding access to critical pages
> (which seems t
* Juergen Gross wrote:
> On 08/08/17 16:00, Boris Ostrovsky wrote:
> > On 08/08/2017 02:46 AM, Juergen Gross wrote:
> >> On 28/07/17 12:23, Juergen Gross wrote:
> >>> This patch series fixes a regression introduced in 4.13-rc1: A Xen
> >>> HVM guest with KASLR enabled wouldn't boot any longer du
On 11/08/17 14:35, Peter Zijlstra wrote:
> On Fri, Aug 11, 2017 at 02:22:25PM +0200, Juergen Gross wrote:
>> Wait - the TLB can be cleared at any time, as Andrew was pointing out.
>> No cpu can rely on an address being accessible just because IF is being
>> cleared. All that matters is the existing
* Thomas Garnier wrote:
> Changes:
> - v2:
>- Add support for global stack cookie while compiler default to fs without
> mcmodel=kernel
>- Change patch 7 to correctly jump out of the identity mapping on kexec
> load
> preserve.
>
> These patches make the changes necessary to
On Thu 2017-08-10 10:26:05, Thomas Garnier wrote:
> Change the assembly code to use only relative references of symbols for the
> kernel to be PIE compatible.
>
> Position Independent Executable (PIE) support will allow to extended the
> KASLR randomization range below the -2G memory limit.
>
> S
On Fri, Aug 11, 2017 at 02:22:25PM +0200, Juergen Gross wrote:
> Wait - the TLB can be cleared at any time, as Andrew was pointing out.
> No cpu can rely on an address being accessible just because IF is being
> cleared. All that matters is the existing and valid page table entry.
>
> So clearing
flight 112577 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112577/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 7 reboot fail REGR. vs. 110515
test-amd64-amd64-xl
>>> On 27.07.17 at 18:19, wrote:
> On Wed, Jul 5, 2017 at 11:05 AM, Jan Beulich wrote:
>> Calculate entry PFN and flags just once. Convert the two successive
>> main if()-s to and if/elf-if chain. Restrict variable scope where
>> reasonable. Take the opportunity and also make the induction variab
On 11/08/17 12:56, Peter Zijlstra wrote:
> On Fri, Aug 11, 2017 at 11:23:10AM +0200, Vitaly Kuznetsov wrote:
>> Peter Zijlstra writes:
>>
>>> On Thu, Aug 10, 2017 at 07:08:22PM +, Jork Loeser wrote:
>>>
>> Subject: Re: [tip:x86/platform] x86/hyper-v: Use hypercall for remote
>> TLB fl
flight 112586 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112586/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a
build-arm64-libvirt 1 build-check(1)
On Fri, Aug 11, 2017 at 12:05:45PM +0100, Andrew Cooper wrote:
> >> Oh, I see your concern. Hyper-V, however, is not the first x86
> >> hypervisor trying to avoid IPIs on remote TLB flush, Xen does this
> >> too. Briefly looking at xen_flush_tlb_others() I don't see anything
> >> special, do we kno
>>> On 27.07.17 at 18:19, wrote:
> On Wed, Jul 5, 2017 at 11:05 AM, Jan Beulich wrote:
>> Calculate entry PFN and flags just once. Convert the two successive
>> main if()-s to and if/elf-if chain. Restrict variable scope where
>> reasonable. Take the opportunity and also make the induction variab
On Thu, Aug 10, 2017 at 03:42:24PM -0600, Jim Fehlig wrote:
> On 08/08/2017 09:09 AM, Wei Liu wrote:
> > Ian and Stefano
> >
> > Oleksandr discovered that the p9fs array in libxl_domain_config is name
> > p9 instead of p9s. This causes problem for his work to rework device
> > framework.
> >
> >
Hi Andrii,
Thank you very much for your feedback, please see my answers below.
On Thu, Aug 10, 2017 at 1:13 PM, Andrii Anisov
wrote:
> Dear Mirela,
>
> Please see my comments below:
>
>
>
> On 09.08.17 20:43, Mirela Simonovic wrote:
>
>> This document contains our draft proposal for implementin
1 - 100 of 117 matches
Mail list logo
