On Fri, Sep 30, 2016 at 03:46:54AM -0600, Jan Beulich wrote:
> >>> On 29.09.16 at 23:42, wrote:
> > +#else
> > +static void __init free_ebmalloc_unused_mem(void)
> > +{
> > +}
> > +#endif
>
> Did you build test this for ARM? The function ought to be unused,
> as ...
>
> > @@ -1251,6 +1301,8 @@ voi
flight 67795 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67795/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like
6
test-amd64-a
From: casionwoo
Comment of origin code said "wait max 10 ms until cpu is on"
Origin code expects to print "CPU%d power enable failed", if cpu do not on
until 10ms
But actual code do not reach to print even it wait 10 ms (actually it waits
11ms not 10ms)
Because the comparing is like bellow
"if
flight 101257 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101257/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 11 guest-start fail REGR. vs. 101189
test-amd64-amd64-xl-qemu
On 02/10/16 23:45, Boris Ostrovsky wrote:
> xen_cpuhp_setup() calls mutex_lock() which, when CONFIG_DEBUG_MUTEXES
> is defined, ends up calling xen_save_fl(). That routine expects
> per_cpu(xen_vcpu, 0) to be already initialized.
Applied to for-linus-4.9, thanks.
David
__
flight 101279 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101279/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen b7dd797c7fe4cd849018f78f6c7b9eb3d33b89d8
baseline version:
xen b3d5
>>> On 05.10.16 at 06:49, wrote:
> Ok. Adding an hvm_get_cpl seems pretty straightforward. I'll do that.
I've got such a patch already, but it'll be usefully posted only when we
get closer to re-opening the tree for 4.9. It definitely wants to do more
than just adding the new wrapper.
Jan
__
Hello,
what's the point of this being used by hvmemul_read() and
hvmemul_cmpxchg(), but (namely but not limited to) not by
hvmemul_write()?
Thanks, Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Hello,
> what's the point of this being used by hvmemul_read() and
> hvmemul_cmpxchg(), but (namely but not limited to) not by
> hvmemul_write()?
To do introspection work, we sometimes need to modify the guest memory,
and there are cases, namely during hibernate / resume of Windows guests,
when w
>>> On 05.10.16 at 14:22, wrote:
>> what's the point of this being used by hvmemul_read() and
>> hvmemul_cmpxchg(), but (namely but not limited to) not by
>> hvmemul_write()?
>
> To do introspection work, we sometimes need to modify the guest memory,
> and there are cases, namely during hibernate
>>> On 05.10.16 at 14:29, wrote:
On 05.10.16 at 14:22, wrote:
>>> what's the point of this being used by hvmemul_read() and
>>> hvmemul_cmpxchg(), but (namely but not limited to) not by
>>> hvmemul_write()?
>>
>> To do introspection work, we sometimes need to modify the guest memory,
>> and
On 05/10/16 13:29, Jan Beulich wrote:
On 05.10.16 at 14:22, wrote:
>>> what's the point of this being used by hvmemul_read() and
>>> hvmemul_cmpxchg(), but (namely but not limited to) not by
>>> hvmemul_write()?
>> To do introspection work, we sometimes need to modify the guest memory,
>> and
On 10/05/2016 03:29 PM, Jan Beulich wrote:
On 05.10.16 at 14:22, wrote:
>>> what's the point of this being used by hvmemul_read() and
>>> hvmemul_cmpxchg(), but (namely but not limited to) not by
>>> hvmemul_write()?
>>
>> To do introspection work, we sometimes need to modify the guest memory
>>> On 21.09.16 at 18:17, wrote:
> On Wed, Sep 21, 2016 at 10:04:21AM -0600, Jan Beulich wrote:
>> >>> On 21.09.16 at 17:59, wrote:
>> > The fix can be done two ways:
>> > a) See if xen.efi.map exists and then copy it
>> > b) Or link xen.efi.map to xen-syms.map (similar to how xen.efi is linked
>>> On 05.10.16 at 14:44, wrote:
> On 10/05/2016 03:29 PM, Jan Beulich wrote:
> On 05.10.16 at 14:22, wrote:
what's the point of this being used by hvmemul_read() and
hvmemul_cmpxchg(), but (namely but not limited to) not by
hvmemul_write()?
>>>
>>> To do introspection work, we
On 10/05/2016 03:47 PM, Jan Beulich wrote:
On 05.10.16 at 14:44, wrote:
>> On 10/05/2016 03:29 PM, Jan Beulich wrote:
>> On 05.10.16 at 14:22, wrote:
> what's the point of this being used by hvmemul_read() and
> hvmemul_cmpxchg(), but (namely but not limited to) not by
> hvme
On 05/10/16 13:52, bla...@riseup.net wrote:
> George Dunlap:
>> On Wed, Oct 5, 2016 at 11:16 AM, wrote:
>>>
>>> Hi all,
>>> I have been wondering if I could manage to make Xen function on my
>>> laptop, using as dom0 my Arch Linux installation. As far as I understood
>>> there is no currently sup
On 10/05/2016 04:02 PM, Jan Beulich wrote:
On 05.10.16 at 14:53, wrote:
>> On 10/05/2016 03:47 PM, Jan Beulich wrote:
>> On 05.10.16 at 14:44, wrote:
On 10/05/2016 03:29 PM, Jan Beulich wrote:
On 05.10.16 at 14:22, wrote:
>>> what's the point of this being used by hvme
>>> On 05.10.16 at 14:53, wrote:
> On 10/05/2016 03:47 PM, Jan Beulich wrote:
> On 05.10.16 at 14:44, wrote:
>>> On 10/05/2016 03:29 PM, Jan Beulich wrote:
>>> On 05.10.16 at 14:22, wrote:
>> what's the point of this being used by hvmemul_read() and
>> hvmemul_cmpxchg(), but (nam
On 05/10/16 14:02, George Dunlap wrote:
> On 05/10/16 13:52, bla...@riseup.net wrote:
>> George Dunlap:
>>> On Wed, Oct 5, 2016 at 11:16 AM, wrote:
Hi all,
I have been wondering if I could manage to make Xen function on my
laptop, using as dom0 my Arch Linux installation. As far as
On 10/05/2016 03:40 PM, Andrew Cooper wrote:
> On 05/10/16 13:29, Jan Beulich wrote:
> On 05.10.16 at 14:22, wrote:
what's the point of this being used by hvmemul_read() and
hvmemul_cmpxchg(), but (namely but not limited to) not by
hvmemul_write()?
>>> To do introspection work,
hvmemul_cmpxchg() sets the read emulation context in p_new instead
of p_old, which is inconsistent (and wrong). We are now setting
p_old (even though it's unused) and adding a comment explaining
the change.
Suggested-by: Jan Beulich
Signed-off-by: Razvan Cojocaru
---
xen/arch/x86/hvm/emulate.c
On 05/10/16 14:12, Razvan Cojocaru wrote:
> On 10/05/2016 03:40 PM, Andrew Cooper wrote:
>> On 05/10/16 13:29, Jan Beulich wrote:
>> On 05.10.16 at 14:22, wrote:
> what's the point of this being used by hvmemul_read() and
> hvmemul_cmpxchg(), but (namely but not limited to) not by
>>> On 05.10.16 at 15:19, wrote:
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1031,13 +1031,17 @@ static int hvmemul_cmpxchg(
>
> if ( unlikely(hvmemul_ctxt->set_context) )
> {
> -int rc = set_context_data(p_new, bytes);
> +int rc = set_co
On 10/05/2016 04:43 PM, Jan Beulich wrote:
On 05.10.16 at 15:19, wrote:
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -1031,13 +1031,17 @@ static int hvmemul_cmpxchg(
>>
>> if ( unlikely(hvmemul_ctxt->set_context) )
>> {
>> -int rc = set_con
>>> On 05.10.16 at 15:32, wrote:
> Here it comes xl dmesg with Xen booted with e820-verbose=true
I have to admit that the only way I can see
(XEN) Initial Xen-e820 RAM map:
(XEN) - 0009ec00 (usable)
(XEN) 0009ec00 - 000a (reserved)
(XEN) 00
>>> On 05.10.16 at 15:54, wrote:
> On 10/05/2016 04:43 PM, Jan Beulich wrote:
>> So with this I wonder btw. why your patch (mostly) fixing this
>> shortcoming (while adding proper LOCK handling) never made it
>> to a version that could be committed.
>
> I was under the impression that your stand
On 10/05/2016 05:05 PM, Jan Beulich wrote:
On 05.10.16 at 15:54, wrote:
>> On 10/05/2016 04:43 PM, Jan Beulich wrote:
>>> So with this I wonder btw. why your patch (mostly) fixing this
>>> shortcoming (while adding proper LOCK handling) never made it
>>> to a version that could be committed.
hvmemul_cmpxchg() sets the read emulation context in p_new instead
of p_old, which is inconsistent (and wrong). Since p_old is
unused in any case and cmpxchg() semantics would be altered even
if it wasn't, remove the emulation context setting code.
Suggested-by: Jan Beulich
Signed-off-by: Razvan
Commit ed04ca introduced a bug in the symtab/strtab loading for 32bit
guests, that corrupted the section headers array due to the padding
introduced by the elf_shdr union.
The Elf section header array on 32bit should be accessible as an array of
Elf32_Shdr elements, and the union with Elf64_Shdr d
flight 101282 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101282/
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 1
On Tue, Oct 04, 2016 at 10:24:04AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 04, 2016 at 01:35:41PM +, Paul Durrant wrote:
> > > -Original Message-
> > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > > Sent: 04 October 2016 13:52
> > > To: Paul Durrant ; annie.
On Wed, Oct 05, 2016 at 05:30:26PM +0200, Roger Pau Monné wrote:
> [...]
> Also, IIRC NetBSD doesn't have a Xen GSO implementation [1], but I would let
> Manuel answer that one.
I confirm, we don't support GSO at this time.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la d
Hello Daniel,
On 05/10/2016 00:02, Daniel Kiper wrote:
On Fri, Sep 30, 2016 at 03:46:54AM -0600, Jan Beulich wrote:
On 29.09.16 at 23:42, wrote:
+#else
+static void __init free_ebmalloc_unused_mem(void)
+{
+}
+#endif
Did you build test this for ARM? The function ought to be unused,
as ...
>>> On 05.10.16 at 17:11, wrote:
> --- a/xen/common/libelf/libelf-loader.c
> +++ b/xen/common/libelf/libelf-loader.c
> @@ -262,13 +262,14 @@ static void elf_load_bsdsyms(struct elf_binary *elf)
> } __attribute__((packed)) header;
>
> ELF_HANDLE_DECL(elf_ehdr) header_handle;
> -unsi
On Wed, Oct 05, 2016 at 09:51:06AM -0600, Jan Beulich wrote:
> >>> On 05.10.16 at 17:11, wrote:
> > --- a/xen/common/libelf/libelf-loader.c
> > +++ b/xen/common/libelf/libelf-loader.c
> > @@ -262,13 +262,14 @@ static void elf_load_bsdsyms(struct elf_binary *elf)
> > } __attribute__((packed))
Early during boot topology_update_package_map() computes
logical_pkg_ids for all present processors.
Later, when processors are brought up, identify_cpu() updates
these values based on phys_pkg_id which is a function of
initial_apicid. On PV guests the latter may point to a
non-existing node, caus
flight 101268 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101268/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-cubietruck 16 guest-start.2 fail in 101256 pass in 101268
test-amd64-amd64-xl-qemuu-ovm
On 05/10/16 18:09, Boris Ostrovsky wrote:
> Early during boot topology_update_package_map() computes
> logical_pkg_ids for all present processors.
>
> Later, when processors are brought up, identify_cpu() updates
> these values based on phys_pkg_id which is a function of
> initial_apicid. On PV gue
On Tue, Oct 4, 2016 at 3:23 PM, George Dunlap wrote:
> Thanks for this -- if you're up for it, let me see what kinds of next
> steps you can do (obviously when you have the opportunity).
So there are a couple of things we could do next.
* If you want a simple change that you can use to get exper
This run is configured for baseline tests only.
flight 67796 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67796/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-a
flight 101269 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101269/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 101240
test-amd64-amd64-xl-qemuu-
Hi Jan,
Sorry for the late answer, I have been traveling the past 2 weeks.
On 30/09/2016 02:46, Jan Beulich wrote:
On 29.09.16 at 23:42, wrote:
+#else
+static void __init free_ebmalloc_unused_mem(void)
+{
+}
+#endif
Did you build test this for ARM? The function ought to be unused,
as ...
Hi Ian,
On 04/10/2016 10:05, Ian Jackson wrote:
Ian Jackson writes ("[OSSTEST PATCH 1/2] libvirt: Check migration capabilities using
proper XML parser"):
Do not grep the virsh capabilities output (!) Instead, parse the XML
using perl's XML modules and look for the specific feature flag using
On Thu, Sep 15, 2016 at 10:22:36PM +0800, Lan, Tianyu wrote:
> Hi Andrew:
> Sorry to bother you. To make sure we are on the right direction, it's
> better to get feedback from you before we go further step. Could you
> have a look? Thanks.
>
> On 8/17/2016 8:05 PM, Lan, Tianyu wrote:
> > Hi All:
>
Pls cc: me with any replies.
On Monday, 26 September 2016, 15:27:59 EDT, jim burns wrote:
> Unless you have any other ideas, I'm giving up for now. Thanx for your help.
Things have changed on the Hipster branch of OI, giving me a new environment
to test.
Mainly, they have ditched legacy grub in
On Wednesday, 5 October 2016, 11:57:11 EDT, Kevin Brooks wrote:
> Sure. Jim can access webmail at https://mail.netgate.net/webmail
>
> Jim should have a document from us with all of his settings, including the
> link to webmail.
- can someone other than the OP verify that this is a legitimat
Hello Tamas and Ravzan,
I have been looking into mem access support on ARM and I am wondering
how we expect the flags MEM_ACCESS_{R,W,X} to be used when the
permission fault is happening during stage 1 page table walk.
For instance, if the fault is happening when the processor is loading an
flight 101270 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101270/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-raw 13 guest-sav
Hello Julien,
> I have been looking into mem access support on ARM and I am wondering
> how we expect the flags MEM_ACCESS_{R,W,X} to be used when the
> permission fault is happening during stage 1 page table walk.
>
> For instance, if the fault is happening when the processor is loading an
> ins
Hi Julien,
It is expected that certain combinations of mem_access flags will put the
domain into unstable condition, resulting in a crash or a hang. As Razvan
mentioned, on x86 we can end up triggering EPT misconfiguration with the
wrong set of flags. The user of the API is expected to know what he
On 05/10/2016 13:23, Tamas K Lengyel wrote:
Hi Julien,
It is expected that certain combinations of mem_access flags will put
the domain into unstable condition, resulting in a crash or a hang. As
Razvan mentioned, on x86 we can end up triggering EPT misconfiguration
with the wrong set of flags.
On Tue, 2016-10-04 at 20:18 -0400, tevin.k.mall...@gmail.com wrote:
> Hello Jesus!
>
> Thank you for taking the time out of your busy schedule to responded.
> I would love a summary of the small contribution over email, as this
> will allow me to get started on the project sooner. I am located in
This run is configured for baseline tests only.
flight 67805 xen-4.4-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67805/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xend
This run is configured for baseline tests only.
flight 67806 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67806/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm
On 10/04/2016 11:02 AM, Ian Jackson wrote:
Do not grep the virsh capabilities output (!) Instead, parse the XML
using perl's XML modules and look for the specific feature flag using
an XPATH pattern.
AFAICT from looking at the XML, that's
But the original code
On 10/04/2016 11:02 AM, Ian Jackson wrote:
Currently, osstest wrongly thinks that ARM can do save/restore,
because `virsh help' does mention the save command (on all
architectures).
Additionally, check the virth capabilities xpath
/capabilities/host/migration_features
to try to see whether th
flight 101272 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101272/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 9 debian-install fail like 101197
test-amd64-amd64-xl-qemu
flight 101274 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101274/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 9 debian-di-installfail REGR. vs. 101250
test-armhf-armhf-x
flight 101297 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101297/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2cf9ecd2262e4098171fa27c97b56d483f5cf3b4
baseline version:
ovmf c0b7e2b2bfc2748112607
flight 101275 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101275/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-qemuu-nested-intel 10 nested-setup fail in 101258 pass in
101275
test-armhf-armhf-xl
61 matches
Mail list logo
