Hi Michael, Stefano and Julien,
On 22.07.2016 03:16, Stefano Stabellini wrote:
On Thu, 21 Jul 2016, Michael Turquette wrote:
Quoting Stefano Stabellini (2016-07-14 03:38:04)
On Thu, 14 Jul 2016, Dirk Behme wrote:
On 13.07.2016 23:03, Michael Turquette wrote:
Quoting Dirk Behme (2016-07-13 11
The current VBD layer reserves buffer space for each attached device based on
three statically configured settings which are read at boot time.
* max_indirect_segs: Maximum amount of segments.
* max_ring_page_order: Maximum order of pages to be used for the shared ring.
* max_queues: Maximum of
In fact, when not finding a suitable runqueue where to
place a vCPU, and hence using a fallback, we either:
- don't issue any trace record (while we should, at
least, output the chosen pcpu),
- risk underruning when accessing the runqueues
array, while preparing the trace record.
Fix both
This run is configured for baseline tests only.
flight 66814 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66814/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm
> What other debug info can help figure out this specific problem?
I found this post with some suggestions and additional references
Troubleshooting UEFI related problems
https://www.qubes-os.org/doc/uefi-troubleshooting/
I tried different combinations of
/mapbs, /noexitboot
on the EFI
On Wed, 20 Jul 2016, Julien Grall wrote:
> Some p2m functions do not care about the domain except to get the
> associate p2m.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> xen/arch/arm/p2m.c | 16 +++-
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> dif
On Wed, 20 Jul 2016, Julien Grall wrote:
> The function to flush the TLBs for a given p2m does not need to know about
> the domain. So pass directly the p2m in parameter.
>
> At the same time rename the function to p2m_flush_tlb to match the
> parameter change.
>
> Signed-off-by: Julien Grall
R
On Wed, 20 Jul 2016, Julien Grall wrote:
> The function flush_tlb_domain is not used outside of the file where it
> has been declared.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> xen/arch/arm/p2m.c | 2 +-
> xen/include/asm-arm/flushtlb.h | 3 ---
> 2 files
On Wed, 20 Jul 2016, Julien Grall wrote:
> p2m_restore_state is the last caller of p2m_load_VTTBR and already check
> if the vCPU does not belong to the idle domain.
>
> Note that it is likely possible to remove some isb in the function
> p2m_restore_state, however this is not the purpose of this
On Wed, 20 Jul 2016, Julien Grall wrote:
> The current implementation of flush_tlb_domain is relying on the domain
> to have a single p2m. With the upcoming feature altp2m, a single domain
> may have different p2m. So we would need to switch to the correct p2m in
> order to flush the TLBs.
>
> Rat
On Wed, 20 Jul 2016, Julien Grall wrote:
> The function p2m_restore_state could be called with an idle vCPU in
> arguments (when called by construct_dom0). However, we will never return
> to EL0/EL1 in this case, so it is not necessary to restore the p2m
> registers.
>
> Signed-off-by: Julien Gral
On Wed, 20 Jul 2016, Julien Grall wrote:
> The field vttbr holds the base address of the translation table for
> guest. Its value will depends on how the p2m has been initialized and
> will only be used by the code code.
^ code code?
> So move the field from arch_domain
On Wed, 20 Jul 2016, Julien Grall wrote:
> The p2m root table does not need to be allocate separately.
>
> Also remove unnecessary fields initialization as the structure is already
> memset to 0 and the fields will be override by p2m_alloc_table.
^ overridden
On Wed, 20 Jul 2016, Julien Grall wrote:
> P2M reads do not require to be serialized. This will add contention
> when PV drivers are using multi-queue because parallel grant
> map/unmaps/copies will happen on DomU's p2m.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> I
On Wed, 20 Jul 2016, Julien Grall wrote:
> Some functions in the p2m code do not require to modify the P2M code.
> Document it by introducing separate helpers to lock the p2m.
>
> This patch does not change the lock. This will be done in a subsequent
> patch.
>
> Signed-off-by: Julien Grall
Rev
On Wed, 20 Jul 2016, Julien Grall wrote:
> The p2m is not yet in use when p2m_init and p2m_allocate_table are
> called. Furthermore the p2m is not used anymore when p2m_teardown is
> called. So taking the p2m lock is not necessary.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
On Wed, 20 Jul 2016, Julien Grall wrote:
> Currently, mfn_to_p2m_entry is relying on the caller to provide the
> correct memory attribute and will deduce the sharability based on it.
>
> Some of the callers, such as p2m_create_table, are using same memory
> attribute regardless the underlying p2m
I'm running Xen-4.7.0_08-452 + linux kernel 4.7.0-4.g89a2ada-default on X86_64
UEFI hardware.
If I boot without Xen hypervisor enabled it boots fine.
If I boot with Xen enabled it PANICs:
(XEN) [2016-07-26 22:05:33] Hardware Dom0 crashed: rebooting machine in
5 seconds.
On Wed, 20 Jul 2016, Julien Grall wrote:
> Currently, the p2m type p2m_mmio_direct is used to map in stage-2
> cacheable MMIO (via map_regions_rw_cache) and non-cacheable one (via
> map_mmio_regions). The p2m code is relying on the caller to give the
> correct memory attribute.
>
> In a follow-up
On Wed, 20 Jul 2016, Julien Grall wrote:
> Currently, the check in get_page_from_gfn is using a blacklist. This is
> very fragile because we may forgot to update the check when a new p2m
> type is added.
>
> To avoid any possible issue, use a whitelist. All type backed by a RAM
> page can could po
On 26/07/2016 16:49, George Dunlap wrote:
> On Tue, Jul 26, 2016 at 4:22 PM, Tamas K Lengyel
> wrote:
>> On Tue, Jul 26, 2016 at 3:12 AM, George Dunlap
>> wrote:
>>> On Wed, Jul 20, 2016 at 7:01 PM, Tamas K Lengyel
>>> wrote:
Currently mem-sharing can be performed on a page-by-page basis f
On Wed, 20 Jul 2016, Julien Grall wrote:
> The resulting assembly code for the macros is much simpler and will
> never contain more than one instruction branch.
>
> The idea is taken from x86 (see include/asm-x86/p2m.h). Also move the
> two helpers earlier to keep all the p2m type definitions toge
On Thu, Jul 21, 2016 at 05:07:23PM +0100, George Dunlap wrote:
> >
> > == Toolstack ==
> >
> > * Make ACPI builder available to components other than hvmloader
> > - Boris Ostrovsky
> >
> > * Libxl PVSCSI support
> > - Olaf Hering
> >
> > * HVM USB passthrough
> > - George Dunlap
>
On Wed, 20 Jul 2016, Julien Grall wrote:
> No functional change.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> xen/include/asm-arm/p2m.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index
On Wed, 20 Jul 2016, Julien Grall wrote:
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/p2m.c | 17 +
> 1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index d82349c..99be9be 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/
On Wed, 20 Jul 2016, Julien Grall wrote:
> The physical address is computed from the machine frame number, so
> checking if the physical address is page aligned is pointless.
>
> Furthermore, directly assigned the MFN to the corresponding field in the
> entry rather than converting to a physical a
On Wed, 20 Jul 2016, Shanker Donthineni wrote:
> The maximum number of mmio handlers that are allowed is limited to
> a macro MAX_IO_HANDLER(16), which is not enough for supporting per CPU
> Redistributor regions. We need at least MAX_IO_HANDLER+CONFIG_NR_CPUS
> mmio handlers in order to support AC
Hi Shanker,
On 20/07/2016 15:00, 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. In worst case scenario,
it would require 144 iterations
Hi Shanker,
On 20/07/2016 15:00, Shanker Donthineni wrote:
Compute the number of mmio handlers that are required for vGICv3 and
vGICv2 emulation drivers in vgic_v3_init()/vgic_v2_init(). Augment
this variable number of mmio handers to a fixed number MAX_IO_HANDLER
s/handers/handlers/
and pas
flight 99698 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99698/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs.
96188
test-amd64-i386-x
On Tue, 26 Jul 2016, Vitaly Kuznetsov wrote:
> David Vrabel writes:
>
> > On 26/07/16 13:30, 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
flight 99701 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99701/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-build fail REGR. vs. 96211
test-amd64-i386-xl-qemu
On Mon, 2016-07-25 at 17:12 +0100, Anshul Makkar wrote:
> It introduces context-switch rate-limiting. The patch enables the VM
> to batch
> its work and prevents the system from spending most of its time in
> context
> switches because of a VM that is waking/sleeping at high rate.
>
> ratelimit ca
Currently the code that calculates the cache attributes of the HAP page
tables assume that if MTRR are disabled the memory type is UC, this can
cause issues if MTRR are never enabled because the guest only plans to use
PAT.
In order to solve this modify epte_get_entry_emt so that is takes into
acc
On Tue, Jul 26, 2016 at 04:58:10PM +0800, Bob Liu wrote:
>
> On 07/26/2016 04:44 PM, Roger Pau Monné wrote:
> > On Tue, Jul 26, 2016 at 01:19:37PM +0800, Bob Liu wrote:
> >> The current VBD layer reserves buffer space for each attached device based
> >> on
> >> three statically configured setting
On Tue, Jul 26, 2016 at 4:22 PM, Tamas K Lengyel
wrote:
> On Tue, Jul 26, 2016 at 3:12 AM, George Dunlap
> wrote:
>> On Wed, Jul 20, 2016 at 7:01 PM, Tamas K Lengyel
>> wrote:
>>> Currently mem-sharing can be performed on a page-by-page basis from the
>>> control
>>> domain. However, this proc
> -Original Message-
> From: Olaf Hering [mailto:o...@aepfle.de]
> Sent: 26 July 2016 16:45
> To: Paul Durrant
> Cc: Konrad Rzeszutek Wilk; zhigang.x.w...@oracle.com; Wei Liu; Stefano
> Stabellini; Andrew Cooper; xen-devel@lists.xen.org; Anthony Perard
> Subject: Re: [Xen-devel] live migrat
Change the message so that it mentions running from the top level directory
and using '-C xen' in order to call the 'menuconfig' target inside of the
xen directory (there's no top-level menuconfig target).
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
C
On Thu, May 26, Paul Durrant wrote:
> It's likely to be a while before I could find some time for this;
> rough guess would be a month... It depends how other stuff pans out.
Any news, Paul? Did you have a chance to compose a fix?
Olaf
signature.asc
Description: PGP signature
_
On 26/07/16 13:15, Juergen Gross wrote:
> pv_time_ops might be overwritten with xen_time_ops after the
> steal_clock operation has been initialized already. To prevent calling
> a now uninitialized function pointer add the steal_clock static
> initialization to xen_time_ops.
Applied to for-linus-4
On Tue, Jul 26, 2016 at 4:25 AM, George Dunlap
wrote:
> On Tue, Jul 26, 2016 at 10:35 AM, George Dunlap
> wrote:
>> On Mon, Jul 25, 2016 at 7:33 PM, Tamas K Lengyel
>> wrote:
>>> Move sharing locks above altp2m to avoid locking order violation and
>>> crashing
>>> the hypervisor during unsharin
On Tue, Jul 26, 2016 at 3:12 AM, George Dunlap wrote:
> On Wed, Jul 20, 2016 at 7:01 PM, Tamas K Lengyel
> wrote:
>> Currently mem-sharing can be performed on a page-by-page basis from the
>> control
>> domain. However, this process is quite wasteful when a range of pages have to
>> be deduplica
On 07/26/2016 12:01 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the xen-tip tree got a conflict in:
>
> arch/x86/xen/enlighten.c
>
> between commit:
>
> 4c9075835511 ("xen/x86: Move irq allocation from Xen smp_op.cpu_up()")
>
> from the tip tree and commit:
>
> 88e95
Wei Liu writes ("Re: [Xen-devel] [PATCH 3/4] tools/libxc: Avoid generating
inappropriate zero-length records"):
> On Mon, Jul 25, 2016 at 06:15:37PM +0100, Ian Jackson wrote:
> > Is the ultimate bug that we are tripping over here simply that the
> > code calls malloc(0) and then bails if the libc
David Vrabel writes:
> On 26/07/16 13:30, 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 vC
On 26/07/16 13:30, 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'
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
---
Changes since v1:
- Use xen_vcpu_nr() helper [David Vr
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. Convert all callers of HYPERVISOR_vcpu_op() to use
xen_vcpu_nr(). Leave xen_fill_possible_map() and xen_filter_cpu_maps()
intact as they're
Currently we don't save ACPI ids (unlike LAPIC ids which go to
x86_cpu_to_apicid) from MADT and we may need this information later.
Particularly, ACPI ids is the only existent way for a PVHVM Xen guest
to figure out Xen's idea of its vCPUs ids before these CPUs boot and
in some cases these ids dive
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
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
---
Changes since v1:
- Use xen_vcpu_nr() helper [David Vrabel]
---
drivers/xen/events/events_fif
Use the newly introduced xen_vcpu_id mapping to get Xen's idea of vCPU id
for CPU0.
Signed-off-by: Vitaly Kuznetsov
---
Changes since v1:
- Use xen_vcpu_nr() helper [David Vrabel]
---
drivers/xen/evtchn.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/evtchn.c
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
---
Changes since v1:
- Use xen_vcpu_nr() helper [David Vrabel]
---
drivers/x
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
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
flight 99696 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99696/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 guest-saverestorefail never pass
test-armhf-armhf-libvirt 12 migrate-sup
This run is configured for baseline tests only.
flight 66812 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66812/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 136c648f5985a725fbd399085c16932a4c2f65d7
baseline v
pv_time_ops might be overwritten with xen_time_ops after the
steal_clock operation has been initialized already. To prevent calling
a now uninitialized function pointer add the steal_clock static
initialization to xen_time_ops.
Signed-off-by: Juergen Gross
---
arch/x86/xen/time.c | 1 +
driver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2016-6259 / XSA-183
version 5
x86: Missing SMAP whitelisting in 32-bit exception / event delivery
UPDATES IN VERSION 5
Public release.
ISSUE DESCRIPTION
==
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2016-6258 / XSA-182
version 3
x86: Privilege escalation in PV guests
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
=
flight 99685 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99685/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 9 debian-installfail REGR. vs. 97664
test-armhf-armhf-xl-
flight 99707 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99707/
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
flight 99672 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99672/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail REGR. vs. 97740
test-amd64-amd64-xl-qemuu-wi
On Tue, Jul 19, 2016 at 02:48:30PM +0100, Wei Liu wrote:
> This email only tracks big items for xen.git tree. Please reply for items you
> woulk like to see in 4.8 so that people have an idea what is going on and
> prioritise accordingly.
>
> You're welcome to provide description and use cases of t
On Mon, 2016-07-25 at 15:36 +0100, anshul makkar wrote:
> On 22/07/16 11:36, Dario Faggioli wrote:
> >
> > This version is an improvement, but it looks to me that you've
> > missed a
> > few of the review comments to v1.
>
> Sorry about that. !!
>
NP. It's indeed something quite important... but i
On Tue, Jul 26, 2016 at 10:35 AM, George Dunlap
wrote:
> On Mon, Jul 25, 2016 at 7:33 PM, Tamas K Lengyel
> wrote:
>> Move sharing locks above altp2m to avoid locking order violation and crashing
>> the hypervisor during unsharing operations when altp2m is active.
>>
>> Applying mem_access settin
On 26/07/16 11:14, Ian Jackson wrote:
> Andrew Cooper writes ("[XTF PATCH v3] Correct the usage of $(DESTDIR) and
> $(PREFIX)"):
>> The GNU coding standards expect $(DESTDIR) to be the root of everything
>> installed, and for $(PREFIX) to then be added to the path. This is not how
>> XTF previous
Wei Liu writes ("[PATCH] xsm: don't require configuring tools to build xen xsm
blob"):
> Starting from 08cffe66 ("xsm: add a default policy to .init.data") we
> can attach a xsm policy blob to hypervisor. To build that policy blob
> now hypervisor build system needs to enter tools directory.
>
>
Andrew Cooper writes ("[XTF PATCH v3] Correct the usage of $(DESTDIR) and
$(PREFIX)"):
> The GNU coding standards expect $(DESTDIR) to be the root of everything
> installed, and for $(PREFIX) to then be added to the path. This is not how
> XTF previously behaved.
>
> XTF is not a typical package
flight 99697 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99697/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 136c648f5985a725fbd399085c16932a4c2f65d7
baseline version:
ovmf daea123d247aebb01f6c54e
On Tue, Jul 26, 2016 at 10:52:13AM +0100, Julien Grall wrote:
>
>
> On 25/07/16 12:53, Wei Liu wrote:
> >On Mon, Jul 25, 2016 at 12:34:53PM +0100, Julien Grall wrote:
> >>
> >>
> >>On 25/07/16 12:11, Wei Liu wrote:
> >>>Thanks for investigating.
> >>>
> >>>There are only two arm related changes i
flight 66811 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66811/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 4 capture-logsbroken R
Wei Liu writes ("Re: [PATCH] tools/libxc: Properly increment ApicIdCoreSize
field on AMD"):
> On Mon, Jul 25, 2016 at 12:33:37PM +0100, Ian Jackson wrote:
> > Wei Liu writes ("Re: [PATCH] tools/libxc: Properly increment ApicIdCoreSize
> > field on AMD"):
> > > Ian, this is a backport candidate an
On 25/07/16 12:53, Wei Liu wrote:
On Mon, Jul 25, 2016 at 12:34:53PM +0100, Julien Grall wrote:
On 25/07/16 12:11, Wei Liu wrote:
Thanks for investigating.
There are only two arm related changes in the range being tested:
* a43cc8f - (origin/smoke) arm/traps: fix bug in dump_guest_s1_walk
On 26/07/16 10:30, Dario Faggioli wrote:
> On Mon, 2016-07-25 at 16:28 +0100, George Dunlap wrote:
>> The generic domain creation logic in
>> xen/common/domctl.c:default_vcpu0_location() attempts to try to do
>> initial placement load-balancing by placing vcpu 0 on the least-busy
>> non-primary hyp
On Mon, Jul 25, 2016 at 7:33 PM, Tamas K Lengyel
wrote:
> Move sharing locks above altp2m to avoid locking order violation and crashing
> the hypervisor during unsharing operations when altp2m is active.
>
> Applying mem_access settings or remapping gfns in altp2m views will
> automatically unshar
On Mon, 2016-07-25 at 16:28 +0100, George Dunlap wrote:
> This is pure code motion; no functional change.
>
> Signed-off-by: George Dunlap
> Reviewed-by: Meng Xu
>
Acked-by: Dario Faggioli
> v2:
> - Rebase on top of Dario's series
>
Thanks and Regards,
Dario
--
<> (Raistlin Majere)
-
On Mon, 2016-07-25 at 16:28 +0100, George Dunlap wrote:
> The generic domain creation logic in
> xen/common/domctl.c:default_vcpu0_location() attempts to try to do
> initial placement load-balancing by placing vcpu 0 on the least-busy
> non-primary hyperthread available. Unfortunately, the logic c
On Mon, Jul 25, 2016 at 06:15:37PM +0100, Ian Jackson wrote:
> David Vrabel writes ("Re: [Xen-devel] [PATCH 3/4] tools/libxc: Avoid
> generating inappropriate zero-length records"):
> > On 21/07/16 18:17, Andrew Cooper wrote:
> > > It was never intended for records such as these to be sent with ze
On 25/07/16 16:28, George Dunlap wrote:
> The initial placement algorithm sometimes picks cpus outside of the
> mask it's given, does a lot of unnecessary bitmasking, does its own
> separate load calculation, and completely ignores vcpu hard and soft
> affinities. Just get rid of it and rely on th
On Mon, 2016-07-25 at 12:17 +0100, George Dunlap wrote:
> On 18/07/16 11:28, Dario Faggioli wrote:
> >
> > On Fri, 2016-07-15 at 19:02 +0100, George Dunlap wrote:
> > >
> > > Signed-off-by: George Dunlap
> > > ---
> > > CC: Dario Faggioli
> > > CC: Anshul Makkar
> > > CC: Meng Xu
> > > CC: Ja
From: Fu Wei
delete: xen_linux, xen_initrd, xen_xsm
add: xen_module
This update bases on
commit 0edd750e50698854068358ea53528100a9192902
Author: Vladimir Serbinenko
Date: Fri Jan 22 10:18:47 2016 +0100
xen_boot: Remove obsolete module type distinctions.
Also bases on the
From: Fu Wei
This patch adds the support of xen_boot command:
xen_hypervisor
xen_module
Also add a new "feature_xen_boot" to indicate this grub support
xen_boot command.
Signed-off-by: Fu Wei
---
grub-core/normal/main.c | 2 +-
util/grub.d/20_linux_xen.in | 13 ++---
2 fi
From: Fu Wei
This patch adds "--nounzip" option support in order to
be compatible with the module command of i386, then we can
simplify grub-mkconfig support code.
Signed-off-by: Fu Wei
---
grub-core/loader/arm64/xen_boot.c | 17 +
1 file changed, 17 insertions(+)
diff --git a
From: Fu Wei
This patchset add xen_boot support into grup-mkconfig for
generating xen boot entrances automatically
Also update the docs/grub.texi for new xen_boot commands.
This patchset has been tested on Foudation model with a bug fix:
http://lists.gnu.org/archive/html/grub-devel/2016-02/msg0
On Mon, 2016-07-25 at 16:28 +0100, George Dunlap wrote:
> The initial placement algorithm sometimes picks cpus outside of the
> mask it's given, does a lot of unnecessary bitmasking, does its own
> separate load calculation, and completely ignores vcpu hard and soft
> affinities. Just get rid of i
From: Fu Wei
Signed-off-by: Fu Wei
---
grub-core/loader/i386/xen.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/grub-core/loader/i386/xen.c b/grub-core/loader/i386/xen.c
index c4d9689..15b0727 100644
--- a/grub-core/loader/i386/xen.c
+++ b/grub-core/loader/i386/xen.c
@@ -689,6 +68
On Wed, Jul 20, 2016 at 7:01 PM, Tamas K Lengyel
wrote:
> Currently mem-sharing can be performed on a page-by-page basis from the
> control
> domain. However, this process is quite wasteful when a range of pages have to
> be deduplicated.
>
> This patch introduces a new mem_sharing memop for rang
On Mon, Jul 25, 2016 at 05:23:18PM +0100, Andrew Cooper wrote:
> The GNU coding standards expect $(DESTDIR) to be the root of everything
> installed, and for $(PREFIX) to then be added to the path. This is not how
> XTF previously behaved.
>
> XTF is not a typical package, and doesn't meet the us
On 07/26/2016 04:44 PM, Roger Pau Monné wrote:
> On Tue, Jul 26, 2016 at 01:19:37PM +0800, Bob Liu wrote:
>> The current VBD layer reserves buffer space for each attached device based on
>> three statically configured settings which are read at boot time.
>> * max_indirect_segs: Maximum amount of
on Mon, Jul 25, 2016 at 06:05:21PM +0100, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH XTF 3/3] xtf-runner: regularise runner exit
> code"):
> > On 25/07/16 12:25, Ian Jackson wrote:
> > > In particular, Error might mask a failure.
> >
> > Indeed it could. Either should cause a prompt
On Tue, Jul 26, 2016 at 01:19:37PM +0800, Bob Liu wrote:
> The current VBD layer reserves buffer space for each attached device based on
> three statically configured settings which are read at boot time.
> * max_indirect_segs: Maximum amount of segments.
> * max_ring_page_order: Maximum order of
Hi all
On 22 February 2016 at 17:29, Fu Wei wrote:
> Hi Julien,
>
> On 20 February 2016 at 00:28, Julien Grall wrote:
>> Xen is currently crashing because of malformed compatible property for
>> the boot module. This is because the property string is not
>> null-terminated as requested by the eP
This run is configured for baseline tests only.
flight 66810 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66810/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf daea123d247aebb01f6c54e10ed1e0b10dfae957
baseline v
On Mon, Jul 25, 2016 at 4:24 PM, Ian Jackson wrote:
> osstest service owner writes ("[xen-unstable-smoke test] 99610: regressions -
> FAIL"):
>> flight 99610 xen-unstable-smoke real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/99610/
>>
>> Regressions :-(
>>
>> Tests which did not s
Stefano Stabellini writes:
> On Mon, 25 Jul 2016, Vitaly Kuznetsov wrote:
>>
>> While we're not obliged to have the same type for xen_vcpu_id on all
>> arches I see no point in diverging without a reason. I can do v3 making
>> the mapping uint32
>
> I agree that making the mapping uint32_t woul
Hi Julien,
On 12 July 2016 at 18:21, Julien Grall wrote:
> Hi Fu Wei,
>
>
> On 06/07/16 18:53, fu@linaro.org wrote:
>>
>> From: Fu Wei
>>
>> This patch adds the support of xen_boot command:
>> xen_hypervisor
>> xen_module
>>
>> Also add a new "feature_xen_boot" to indicate this gru
98 matches
Mail list logo
