This run is configured for baseline tests only.
flight 75145 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75145/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75143
The man page for xf.cfg doesn't say much about strings in the Xen
configuration files, instead it simply says:
"STRING"
A string, surrounded by either single or double quotes. But if the
STRING is part of a SPEC_STRING, the quotes should be omitted.
Nothing about whether single-quotes
This run is configured for baseline tests only.
flight 75144 qemu-upstream-unstable real [real]
http://osstest.xensource.com/osstest/logs/75144/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-pvshim 7 xen-boot
flight 126969 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126969/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stopfail REGR. vs. 124248
Tests which
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, August 30, 2018 11:47 PM
>
> On 30/08/18 15:54, Jan Beulich wrote:
> On 28.08.18 at 19:39, wrote:
> >> The suffix and prefix are redundant, and the name is curiously odd.
> Rename it
> >> to vmx_vcpu to be consistent
This run is configured for baseline tests only.
flight 75143 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75143/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75140
flight 126988 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126988/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 36faa23c46824e3cf9beff8648a56816cbf58f49
baseline version:
ovmf
On 31/08/18 00:14, Boris Ostrovsky wrote:
> On 08/30/2018 07:11 PM, Boris Ostrovsky wrote:
>> On 08/28/2018 01:39 PM, Andrew Cooper wrote:
>>> By making {vmx,svm} in hvm_vcpu into an anonymous union (consistent with
>>> domain side of things), the hvm_{vmx,svm} defines can be dropped, and all
>>>
flight 126952 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126952/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-shadow 20 guest-start/debian.repeat fail REGR. vs. 126854
Tests which did
On 08/30/2018 07:11 PM, Boris Ostrovsky wrote:
> On 08/28/2018 01:39 PM, Andrew Cooper wrote:
>> By making {vmx,svm} in hvm_vcpu into an anonymous union (consistent with
>> domain side of things), the hvm_{vmx,svm} defines can be dropped, and all
>> code
>> refer to the correctly-named fields.
On 08/28/2018 01:39 PM, Andrew Cooper wrote:
> By making {vmx,svm} in hvm_vcpu into an anonymous union (consistent with
> domain side of things), the hvm_{vmx,svm} defines can be dropped, and all code
> refer to the correctly-named fields. This means that the data hierachy is no
> longer obscured
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-qemuu-rhel6hvm-intel
testid redhat-install
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
On 08/29/2018 08:51 PM, Andy Smith wrote:
> Hi,
>
> I'm sorry this is a long email, but I wanted to explain everything
> that I have tried, because it seems like quite a few different
> versions of 32-bit upstream Linux kernel no longer boot as PV guest
> and I'm surprised I am the first to
flight 126966 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126966/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814
build-amd64-libvirt
On 30/08/18 20:46, Julien Grall wrote:
> Hi Andrew,
>
> On 08/29/2018 03:40 PM, Andrew Cooper wrote:
>> For ARM, the call to arch_domain_create() needs to have completed before
>> domain_max_vcpus() will return the correct upper bound.
>>
>> For each arch's dom0's, drop the temporary max_vcpus
Hi Andrew,
On 08/29/2018 03:40 PM, Andrew Cooper wrote:
For ARM, the call to arch_domain_create() needs to have completed before
domain_max_vcpus() will return the correct upper bound.
For each arch's dom0's, drop the temporary max_vcpus parameter, and allocation
of dom0->vcpu.
With
Hi Andrew,
On 08/29/2018 10:38 AM, Andrew Cooper wrote:
... rather than setting the limits up after domain_create() has completed.
This removes the common gnttab infrastructure for calculating the number of
dom0 grant frames (as the common grant table code is not an appropriate place
for it to
Reviewed-by: Pavel Tatashin
On 8/21/18 6:44 AM, David Hildenbrand wrote:
> Let's document the magic a bit, especially why device_hotplug_lock is
> required when adding/removing memory and how it all play together with
> requests to online/offline memory from user space.
>
Reviewed-by: Pavel Tatashin
On 8/21/18 6:44 AM, David Hildenbrand wrote:
> Let's perform all checking + offlining + removing under
> device_hotplug_lock, so nobody can mess with these devices via
> sysfs concurrently.
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
Reviewed-by: Pavel Tatashin
On 8/21/18 6:44 AM, David Hildenbrand wrote:
> device_online() should be called with device_hotplug_lock() held.
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: Rashmica Gupta
> Cc: Balbir Singh
> Cc: Michael Neuling
>
On 8/21/18 6:44 AM, David Hildenbrand wrote:
> There seem to be some problems as result of 30467e0b3be ("mm, hotplug:
> fix concurrent memory hot-add deadlock"), which tried to fix a possible
> lock inversion reported and discussed in [1] due to the two locks
> a) device_lock()
> b)
flight 126938 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126938/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumprun-i386 12 guest-start fail REGR. vs. 125183
> +
> +void __ref remove_memory(int nid, u64 start, u64 size)
Remove __ref, otherwise looks good:
Reviewed-by: Pavel Tatashin
> +{
> + lock_device_hotplug();
> + __remove_memory(nid, start, size);
> + unlock_device_hotplug();
> +}
> EXPORT_SYMBOL_GPL(remove_memory);
> #endif /*
On 8/21/18 6:44 AM, David Hildenbrand wrote:
> add_memory() currently does not take the device_hotplug_lock, however
> is aleady called under the lock from
> arch/powerpc/platforms/pseries/hotplug-memory.c
> drivers/acpi/acpi_memhotplug.c
> to synchronize against CPU hot-remove and
On Tue, 28 Aug 2018, Julien Grall wrote:
> (Switching to my Arm e-mail)
>
> Hi,
>
> On 24/08/18 20:31, Stefano Stabellini wrote:
> > On Fri, 24 Aug 2018, Julien Grall wrote:
> > > Hi,
> > >
> > > On 24/08/18 00:33, Stefano Stabellini wrote:
> > > > Add a kconfig option for Renesas Rcar2
Refreshing XenServer's patchqueue has shown that I missed this adjustment in
the upstream backports of the final version of the XSA-273 fixes.
The code does work in 4.7 and earlier, but only because the eventual value of
(opt_pv_l1tf & OPT_PV_L1TF_DOMx) is within range of a char.
Signed-off-by:
On Thu, Aug 30, 2018 at 09:49:58AM -0600, Jan Beulich wrote:
> >>> On 27.08.18 at 18:55, wrote:
> > Adds support for modifying the LS_CFG MSR to enable SSBD on supporting
> > AMD CPUs. There needs to be locking logic for family 17h with SMT
> > enabled since both threads share the same MSR.
Hi Julien,
On 24.08.18 19:58, Julien Grall wrote:
Signed-off-by: Julien Grall
---
xen/arch/arm/psci.c | 4
xen/include/asm-arm/cpufeature.h | 3 ++-
xen/include/asm-arm/smccc.h | 8
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git
Hi Julien,
On 24.08.18 19:58, Julien Grall wrote:
Some capababilities are set right during boot and will never change
afterwards. At the moment, the function cpu_have_caps will check whether
the cap is enabled from the memory.
It is possible to avoid the load from the memory by using an
flight 126996 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126996/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
flight 126926 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126926/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm 12 guest-start fail REGR. vs. 126042
On 30/08/18 15:07, Jan Beulich wrote:
On 30.08.18 at 14:31, wrote:
>> Callers are inconsistent with whether they pass a newline to panic(),
>> including adjacent calls in the same function using different styles.
>>
>> painc() not expecting a newline is inconsistent with most other printing
flight 126932 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126932/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR.
vs. 126781
On 30/08/18 15:48, Volodymyr Babchuk wrote:
Hi Julien,
Hi,
On 22.08.18 19:46, Julien Grall wrote:
[...]
+++ b/xen/arch/arm/arm32/smc.S
@@ -0,0 +1,39 @@
+/*
+ * xen/arch/arm/arm32/smc.S
+ *
+ * Wrapper for Secure Monitors Calls
+ *
+ * This program is free software; you can redistribute
Hi Julien,
On 24.08.18 19:58, Julien Grall wrote:
Hi all,
This patch series contains fixup and improvement for the SMCCC subsystem.
Patch #1 - #2 are candidates for backporting.
I tested this patches together with my TEE patch series and all is
working fine both with SMCCC 1.0 and SMCCC
On 30/08/18 17:01, Razvan Cojocaru wrote:
> On 8/30/18 6:31 PM, Andrew Cooper wrote:
>> There original reason for this patch was to fix a livepatching problem;
>> unnecesserily large livepatchs due to the use of __LINE__.
>>
>> A second problem is one of debugability. A number of domain_crash()
On 30/08/18 02:39, Tian, Kevin wrote:
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: Wednesday, August 29, 2018 1:39 AM
>>
>> By making {vmx,svm} in hvm_vcpu into an anonymous union (consistent
>> with
>> domain side of things), the hvm_{vmx,svm} defines can be dropped, and all
>>> On 30.08.18 at 17:59, wrote:
> Am Thu, 30 Aug 2018 09:23:47 -0600
> schrieb "Jan Beulich" :
>
>> Reusing? It's been gone since 4.9, and ./INSTALL talks about it as
>> a tool stack only thing.
>
> It does not, it is in the general "make" section.
Quote from ./INSTALL in my copy of the
On 30/08/18 15:52, Jan Beulich wrote:
On 28.08.18 at 19:39, wrote:
On 28.08.18 at 19:39, wrote:
>> The trailing _vcpu suffix is redundant, but adds to code volume. Drop it.
>>
>> Reflow lines as appropriate, and switch to using the new XFREE/etc wrappers
>> where applicable.
> I
On 8/30/18 6:31 PM, Andrew Cooper wrote:
> There original reason for this patch was to fix a livepatching problem;
> unnecesserily large livepatchs due to the use of __LINE__.
>
> A second problem is one of debugability. A number of domain_crash()
> invocations have no logging at all, and number
>>> On 23.08.18 at 11:46, wrote:
> --- a/xen/include/xen/mm.h
> +++ b/xen/include/xen/mm.h
> @@ -26,6 +26,11 @@
> * A linear idea of a guest physical address space. For an auto-translated
> * guest, pfn == gfn while for a non-translated guest, pfn != gfn.
> *
> + * bfn: Bus Frame Number
Am Thu, 30 Aug 2018 09:23:47 -0600
schrieb "Jan Beulich" :
> Reusing? It's been gone since 4.9, and ./INSTALL talks about it as
> a tool stack only thing.
It does not, it is in the general "make" section.
I do not see any valid reason to diverge further.
Olaf
pgp7_TmCXnfBQ.pgp
Description:
On 8/30/18 8:31 AM, David Hildenbrand wrote:
> On 21.08.2018 12:44, David Hildenbrand wrote:
>> This is the same approach as in the first RFC, but this time without
>> exporting device_hotplug_lock (requested by Greg) and with some more
>> details and documentation regarding locking. Tested only
>>> On 27.08.18 at 18:55, wrote:
> Adds support for modifying the LS_CFG MSR to enable SSBD on supporting
> AMD CPUs. There needs to be locking logic for family 17h with SMT
> enabled since both threads share the same MSR. Otherwise, a core just
> needs to write to the LS_CFG MSR. For more
On 30/08/18 15:54, Jan Beulich wrote:
On 28.08.18 at 19:39, wrote:
>> The suffix and prefix are redundant, and the name is curiously odd. Rename
>> it
>> to vmx_vcpu to be consistent with all the other similar structures.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper
>>
>>> On 27.08.18 at 18:54, wrote:
> Edit the initialization code for AMD's SSBD via the LS_CFG MSR and
> enable it to pass the status to the initial spec-ctrl print_details at
> boot.
>
> Signed-off-by: Brian Woods
> ---
I think I had indicated so before: A brief revision log is expected here,
There original reason for this patch was to fix a livepatching problem;
unnecesserily large livepatchs due to the use of __LINE__.
A second problem is one of debugability. A number of domain_crash()
invocations have no logging at all, and number of others only have logging
when compiled with a
>>> On 30.08.18 at 17:20, wrote:
> On 30/08/18 16:15, Jan Beulich wrote:
> On 28.08.18 at 20:11, wrote:
>>> @@ -2478,9 +2478,7 @@ sh_map_and_validate_gl4e(struct vcpu *v, mfn_t gl4mfn,
>>> shadow_l4_index,
>>> validate_gl4e);
>>> On 30.08.18 at 17:10, wrote:
> Creating debug info during build is not strictly required at runtime.
> Make it optional by reusing the existing 'debug_symbols=n' knob.
Reusing? It's been gone since 4.9, and ./INSTALL talks about it as
a tool stack only thing. If we wanted to re-introduce
On 30/08/18 16:15, Jan Beulich wrote:
On 28.08.18 at 20:11, wrote:
>> --- a/xen/arch/x86/mm/hap/hap.c
>> +++ b/xen/arch/x86/mm/hap/hap.c
>> @@ -304,10 +304,11 @@ static void hap_free_p2m_page(struct domain *d, struct
>> page_info *pg)
>> /* Should still have no owner and count zero. */
Uses MD5 on the host mac address, vm name and vif index to generate the
last three bytes of the vm mac address (for each vm).
It uses the vif index to account for multiple vifs.
MD5 code is originally from the public domain (written by Colin Plumb in
1993), files found in
>>> On 28.08.18 at 20:17, wrote:
> hvm_map_entry() can fail for a number of reasons, including for a misaligned
> LDT/GDT access which crosses a 4K boundary. Architecturally speaking, this
> should be fixed, but Long Mode doesn't support task switches, and no 32bit OS
> is going to misalign its
>>> On 28.08.18 at 20:11, wrote:
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -304,10 +304,11 @@ static void hap_free_p2m_page(struct domain *d, struct
> page_info *pg)
> /* Should still have no owner and count zero. */
> if ( owner || (pg->count_info &
Creating debug info during build is not strictly required at runtime.
Make it optional by reusing the existing 'debug_symbols=n' knob.
This slightly reduces build time and diskusage, if specified.
Signed-off-by: Olaf Hering
---
xen/Rules.mk | 5 -
1 file changed, 4 insertions(+), 1
Just kidding (for now), but according to our agreement it would be
ripe: No adjustments towards the better have been made for more
than a year, i.e. in particular nothing has happened with it for the
entire 4.11 and 4.10 release cycles.
Jan
___
flight 126937 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126937/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail in
126844 pass in 126937
>>> On 28.08.18 at 19:39, wrote:
> By making {vmx,svm} in hvm_vcpu into an anonymous union (consistent with
> domain side of things), the hvm_{vmx,svm} defines can be dropped, and all code
> refer to the correctly-named fields. This means that the data hierachy is no
> longer obscured from
>>> On 28.08.18 at 19:39, wrote:
> The suffix and prefix are redundant, and the name is curiously odd. Rename it
> to svm_vcpu to be consistent with all the other similar structures.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger
>>> On 28.08.18 at 19:39, wrote:
> The suffix and prefix are redundant, and the name is curiously odd. Rename it
> to vmx_vcpu to be consistent with all the other similar structures.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger
>>> On 28.08.18 at 19:39, wrote:
>>> On 28.08.18 at 19:39, wrote:
> The trailing _vcpu suffix is redundant, but adds to code volume. Drop it.
>
> Reflow lines as appropriate, and switch to using the new XFREE/etc wrappers
> where applicable.
I couldn't find any such conversion, so perhaps
Hi Julien,
On 22.08.18 19:46, Julien Grall wrote:
[...]
+++ b/xen/arch/arm/arm32/smc.S
@@ -0,0 +1,39 @@
+/*
+ * xen/arch/arm/arm32/smc.S
+ *
+ * Wrapper for Secure Monitors Calls
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU
>>> On 28.08.18 at 19:39, wrote:
> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -173,7 +173,7 @@ static DEFINE_RCU_READ_LOCK(msixtbl_rcu_lock);
> */
> static bool msixtbl_initialised(const struct domain *d)
> {
> -return !!d->arch.hvm_domain.msixtbl_list.next;
> +
flight 126991 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126991/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
>>> On 30.08.18 at 15:06, wrote:
> This allows all system domids to be printed by name, rather than special
> casing the idle vcpus alone.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: George Dunlap
> CC: Jan Beulich
> CC: Konrad Rzeszutek Wilk
> CC: Stefano Stabellini
> CC: Tim Deegan
>
>>> On 30.08.18 at 14:31, wrote:
> Callers are inconsistent with whether they pass a newline to panic(),
> including adjacent calls in the same function using different styles.
>
> painc() not expecting a newline is inconsistent with most other printing
> functions, which is most likely why
>>> On 28.08.18 at 15:12, wrote:
> On 19/07/18 11:49, Jan Beulich wrote:
>> Checking the low 5 bits of CR3 is not the job of vmx_load_pdptrs().
>> Instead it should #GP upon bad PDPTE values, rather than causing a VM
>> entry failure.
>>
>> Signed-off-by: Jan Beulich
>>
>> ---
This allows all system domids to be printed by name, rather than special
casing the idle vcpus alone.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
CC: Julien Grall
RFC, because this was
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Stefano Stabellini
CC: Julien Grall
CC: George Dunlap
CC: Dario Faggioli
---
xen/arch/arm/gic-vgic.c | 12 ++--
xen/common/sched_null.c | 15 ++-
2 files changed, 12 insertions(+), 15 deletions(-)
diff --git
flight 75142 distros-debian-wheezy real [real]
http://osstest.xensource.com/osstest/logs/75142/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-i386-wheezy-netboot-pvgrub 10 debian-di-install fail REGR. vs.
75110
Callers are inconsistent with whether they pass a newline to panic(),
including adjacent calls in the same function using different styles.
painc() not expecting a newline is inconsistent with most other printing
functions, which is most likely why we've gained so many inconsistencies.
Switch
On 21.08.2018 12:44, David Hildenbrand wrote:
> This is the same approach as in the first RFC, but this time without
> exporting device_hotplug_lock (requested by Greg) and with some more
> details and documentation regarding locking. Tested only on x86 so far.
>
I'll be on vacation for two
>>> On 30.08.18 at 14:27, wrote:
> On 30/08/18 13:25, Jan Beulich wrote:
> On 30.08.18 at 11:55, wrote:
>>> --- a/xen/arch/x86/Kconfig
>>> +++ b/xen/arch/x86/Kconfig
>>> @@ -164,3 +164,26 @@ endmenu
>>> source "common/Kconfig"
>>>
>>> source "drivers/Kconfig"
>>> +
>>> +menu "Deprecated
On 30/08/18 13:25, Jan Beulich wrote:
On 30.08.18 at 11:55, wrote:
>> --- a/xen/arch/x86/Kconfig
>> +++ b/xen/arch/x86/Kconfig
>> @@ -164,3 +164,26 @@ endmenu
>> source "common/Kconfig"
>>
>> source "drivers/Kconfig"
>> +
>> +menu "Deprecated Functionality"
>> +
>> +config
>>> On 30.08.18 at 14:22, wrote:
> On 30/08/18 13:02, Jan Beulich wrote:
> On 30.08.18 at 13:18, wrote:
>>> On 30/08/18 12:09, Jan Beulich wrote:
@@ -2512,9 +2512,10 @@ void hvm_emulate_init_per_insn(
hvm_access_insn_fetch,
>>> On 30.08.18 at 11:55, wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -164,3 +164,26 @@ endmenu
> source "common/Kconfig"
>
> source "drivers/Kconfig"
> +
> +menu "Deprecated Functionality"
> +
> +config LEGACY_PV_LDT_PAGING
> + def_bool n
Can this please simply
On 30/08/18 13:02, Jan Beulich wrote:
On 30.08.18 at 13:18, wrote:
>> On 30/08/18 12:09, Jan Beulich wrote:
>>> @@ -2512,9 +2512,10 @@ void hvm_emulate_init_per_insn(
>>> hvm_access_insn_fetch,
>>>
>>> On 30.08.18 at 13:18, wrote:
> On 30/08/18 12:09, Jan Beulich wrote:
>> @@ -2512,9 +2512,10 @@ void hvm_emulate_init_per_insn(
>> hvm_access_insn_fetch,
>> _ctxt->seg_reg[x86_seg_cs],
>>
On 30/08/18 12:09, Jan Beulich wrote:
> @@ -3758,8 +3749,9 @@ void hvm_ud_intercept(struct cpu_user_re
> if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->rip,
> sizeof(sig), hvm_access_insn_fetch,
> cs,
On 30/08/18 12:09, Jan Beulich wrote:
> It can easily be expressed through hvm_copy_from_guest_linear(), and in
> two cases this even simplifies callers.
>
> Suggested-by: Paul Durrant
> Signed-off-by: Jan Beulich
I really like this piece of cleanup, but...
> ---
> v2: New.
>
> ---
Assuming consecutive linear addresses map to all RAM or all MMIO is not
correct. Nor is assuming that a page straddling MMIO access will access
the same emulating component for both parts of the access. If a guest
RAM read fails with HVMTRANS_bad_gfn_to_mfn and if the access straddles
a page
It can easily be expressed through hvm_copy_from_guest_linear(), and in
two cases this even simplifies callers.
Suggested-by: Paul Durrant
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1060,6 +1060,8 @@ static int __hvmemul_read(
1: drop hvm_fetch_from_guest_linear()
2: split page straddling emulated accesses in more cases
Patch 2 is incomplete at this time, and hence only RFC.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On Fri, Aug 24, 2018 at 09:58:02AM +0100, Wei Liu wrote:
> On Wed, Aug 22, 2018 at 04:52:27PM -0600, Jim Fehlig wrote:
> > On 08/21/2018 05:14 AM, Jan Beulich wrote:
> > > > > > On 21.08.18 at 03:11, wrote:
> > > > flight 126201 xen-4.9-testing real [real]
> > > >
flight 126985 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126985/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
On Thu, Aug 30, Jan Beulich wrote:
> approach): One is Paul's idea of making null_handler actually retrieve
> RAM contents when (part of) the access touches RAM. Another might
This works for me:
static int null_read(const struct hvm_io_handler *io_handler,
uint64_t addr,
On Thu, Aug 30, 2018 at 12:05:11PM +0200, Olaf Hering wrote:
> rpmbuild -bb spents alot of time in compressing the binaries. Reduce the
> turnaround time of 'make rpmball' by using gzip as compression tool.
> This reduces the buildtime from 'w9.xzdio'/138 seconds to 'w1.gzdio'/88
> seconds in my
On Thu, Aug 30, 2018 at 03:12:25AM -0600, Jan Beulich wrote:
> >>> On 30.08.18 at 10:51, wrote:
> > On Thu, Aug 30, 2018 at 01:49:44AM -0600, Jan Beulich wrote:
> >> >>> On 30.08.18 at 06:42, wrote:
> >> > flight 126907 xen-4.7-testing real [real]
> >> >
rpmbuild -bb spents alot of time in compressing the binaries. Reduce the
turnaround time of 'make rpmball' by using gzip as compression tool.
This reduces the buildtime from 'w9.xzdio'/138 seconds to 'w1.gzdio'/88
seconds in my environment.
The downside is an increased filesize of xen.rpm, 19MB
This code is believed to be vestigial remnant of the PV Windows XP port. It
is not used by Linux, NetBSD, Solaris or MiniOS. Furthermore the
implementation is incomplete; it only functions for a present => not-present
transition, rather than a present => read/write transition.
The
On 30/08/18 10:26, Jan Beulich wrote:
On 30.08.18 at 09:52, wrote:
>> @@ -202,7 +202,7 @@ static int alloc_trace_bufs(unsigned int pages)
>> * Allocate buffers for all of the cpus.
>> * If any fails, deallocate what you have so far and exit.
>> */
>> -
>>> On 30.08.18 at 10:51, wrote:
> On Thu, Aug 30, 2018 at 01:49:44AM -0600, Jan Beulich wrote:
>> >>> On 30.08.18 at 06:42, wrote:
>> > flight 126907 xen-4.7-testing real [real]
>> > http://logs.test-lab.xenproject.org/osstest/logs/126907/
>> >
>> > Regressions :-(
>> >
>> > Tests which did
flight 126959 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126959/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 497a5fb1d8f834e1bc84d3496d7f2228bf99f7df
baseline version:
ovmf
On Thu, Aug 30, 2018 at 01:49:44AM -0600, Jan Beulich wrote:
> >>> On 30.08.18 at 06:42, wrote:
> > flight 126907 xen-4.7-testing real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/126907/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including
On 2018-08-30 18:33, Jan Beulich wrote:
On 30.08.18 at 06:01, wrote:
Managed to get the same crash log when adding CPUs to Pool-1 as
follows:
Create the pool:
(XEN) Initializing Credit2 scheduler
(XEN) load_precision_shift: 18
(XEN) load_window_shift: 30
(XEN) underload_balance_tolerance:
On 30/08/18 10:43, Jan Beulich wrote:
On 30.08.18 at 10:31, wrote:
>> On 30/08/18 10:16, Jan Beulich wrote:
>> On 29.08.18 at 20:23, wrote:
The topology information obtainable via XEN_SYSCTL_cputopoinfo is
filled rather weird: the size of the array is derived from the highest
On 30/08/18 10:44, Jan Beulich wrote:
On 30.08.18 at 10:37, wrote:
>> On Thu, Aug 30, 2018 at 10:31:16AM +0200, Juergen Gross wrote:
>>> On 30/08/18 10:16, Jan Beulich wrote:
>>> On 29.08.18 at 20:23, wrote:
> The topology information obtainable via XEN_SYSCTL_cputopoinfo is
>
>>> On 30.08.18 at 10:37, wrote:
> On Thu, Aug 30, 2018 at 10:31:16AM +0200, Juergen Gross wrote:
>> On 30/08/18 10:16, Jan Beulich wrote:
>> On 29.08.18 at 20:23, wrote:
>> >> The topology information obtainable via XEN_SYSCTL_cputopoinfo is
>> >> filled rather weird: the size of the array
>>> On 30.08.18 at 10:31, wrote:
> On 30/08/18 10:16, Jan Beulich wrote:
> On 29.08.18 at 20:23, wrote:
>>> The topology information obtainable via XEN_SYSCTL_cputopoinfo is
>>> filled rather weird: the size of the array is derived from the highest
>>> online cpu number, while the data is
>>> On 30.08.18 at 10:11, wrote:
> On 30/08/18 10:07, Jan Beulich wrote:
> On 29.08.18 at 20:23, wrote:
>>> With not all physical cpus online (i.e. with smt=0) the output of hte
>>
>> I think you mean "e.g." instead of "i.e." here, as there are other
>> means to have some CPUs offline.
>
>
On Thu, Aug 30, 2018 at 10:31:16AM +0200, Juergen Gross wrote:
> On 30/08/18 10:16, Jan Beulich wrote:
> On 29.08.18 at 20:23, wrote:
> >> The topology information obtainable via XEN_SYSCTL_cputopoinfo is
> >> filled rather weird: the size of the array is derived from the highest
> >> online
1 - 100 of 134 matches
Mail list logo
