flight 66791 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66791/
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 REGR.
Hi,
Is there an API in Xen to get the page content of a known gfn ?
I want to calculate the checksum of the content of the page and wanna see
if it
is possible ?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 07/25/2016 11:29 AM, sepanta s wrote:
> Hi,
> Is there an API in Xen to get the page content of a known gfn ?
> I want to calculate the checksum of the content of the page and wanna
> see if it
> is possible ?
You can map the page with xc_map_foreign_range(), then just inspect the
memory as if
On Sun, Jul 24, 2016 at 06:06:00PM +0200, Sergej Proskurin wrote:
> Hi Wei,
>
> On 07/07/2016 06:27 PM, Wei Liu wrote:
> > On Mon, Jul 04, 2016 at 01:45:45PM +0200, Sergej Proskurin wrote:
> >> The current implementation allows to set the parameter HVM_PARAM_ALTP2M.
> >> This parameter allows furt
On Thu, Jul 21, 2016 at 10:15 PM, Stefano Stabellini
wrote:
>> You are assuming that the guest will map the ACPI blob with the same
>> attributes as the rest of the superpage.
>>
>> IHMO, a sane operating system will want to map the ACPI blob read-only.
>
> That's true. But there are other things
On 2016/7/20 17:32, Wei Liu wrote:
> On Wed, Jul 20, 2016 at 02:52:05PM +0800, Shannon Zhao wrote:
>> >
>> >
>> > On 2016/7/19 18:38, Wei Liu wrote:
>>> > > On Fri, Jul 15, 2016 at 05:39:32PM +0800, Shannon Zhao wrote:
>>> > > [...]
>>> > >>> > >
>>> > >>> > > It would be trivial to ha
On Fri, Jul 22, 2016 at 03:27:30AM +, osstest service owner wrote:
> flight 97737 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/97737/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-armhf-ar
Hi Wei,
On 07/25/2016 10:32 AM, Wei Liu wrote:
> On Sun, Jul 24, 2016 at 06:06:00PM +0200, Sergej Proskurin wrote:
>> Hi Wei,
>>
>> On 07/07/2016 06:27 PM, Wei Liu wrote:
>>> On Mon, Jul 04, 2016 at 01:45:45PM +0200, Sergej Proskurin wrote:
The current implementation allows to set the parame
Vitaly Kuznetsov writes:
> 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
On Sun, Jul 24, 2016 at 09:26:57PM +0200, Marek Marczykowski-Górecki wrote:
> Having DefaultDependencies=no means it can be started before / is
> remounted read-write, which will result in various failures (to start
> with opening the log).
> Since "libxl: trigger attach events for devices attached
On Sat, Jul 23, 2016 at 06:18:23AM +0800, Bob Liu wrote:
>
> On 07/22/2016 07:45 PM, Roger Pau Monné wrote:
> > On Fri, Jul 22, 2016 at 05:43:32PM +0800, Bob Liu wrote:
> >>
> >> On 07/22/2016 05:34 PM, Roger Pau Monné wrote:
> >>> On Fri, Jul 22, 2016 at 04:17:48PM +0800, Bob Liu wrote:
>
>
On Sun, Jul 24, 2016 at 09:27:13PM +0200, Marek Marczykowski-Górecki wrote:
> It is no longer required since xl devd use /dev/xen interface.
>
How would this unit work when there is no /dev/xen interface?
To be precise, we prefer /dev/xen interfaces whenever possible but there
is a fallback to /
On 25/07/16 07:09, Kang, Luwei wrote:
First of all - please don't top post.
> What about remove the dependency between AVX2 and AVX512F
>> ( AVX2:
[AVX512F], ) ?
Yes, that's what I think we want, but we need Andrew's agreement here.
>>> Hi Andrew, what is your opi
On Mon, Jul 25, 2016 at 10:27:47AM +0100, Wei Liu wrote:
> On Sun, Jul 24, 2016 at 09:27:13PM +0200, Marek Marczykowski-Górecki wrote:
> > It is no longer required since xl devd use /dev/xen interface.
> >
>
> How would this unit work when there is no /dev/xen interface?
Does it happen in realit
On Mon, Jul 25, 2016 at 11:30:32AM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, Jul 25, 2016 at 10:27:47AM +0100, Wei Liu wrote:
> > On Sun, Jul 24, 2016 at 09:27:13PM +0200, Marek Marczykowski-Górecki wrote:
> > > It is no longer required since xl devd use /dev/xen interface.
> > >
> >
> >
On 22.07.2016 12:21, Ingo Jürgensmann wrote:
On 22.07.2016 11:03, Ingo Jürgensmann wrote:
In the meanwhile, I activated IPv6 again on Tuesday evening and today
the server crashed again some minutes ago. Here's the output from
netconsole:
... and the second subsequent crash:
... and another c
On Mon, Jul 25, 2016 at 10:34:21AM +0100, Wei Liu wrote:
> On Mon, Jul 25, 2016 at 11:30:32AM +0200, Marek Marczykowski-Górecki wrote:
> > On Mon, Jul 25, 2016 at 10:27:47AM +0100, Wei Liu wrote:
> > > On Sun, Jul 24, 2016 at 09:27:13PM +0200, Marek Marczykowski-Górecki
> > > wrote:
> > > > It is
On Thu, Jul 21, 2016 at 06:17:34PM +0100, Andrew Cooper wrote:
> The sending side shouldn't send any variable sized records which end up having
> zero content, but the receiving side will need to tolerate such records for
> compatibility purposes.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: We
On Thu, Jul 21, 2016 at 06:17:35PM +0100, Andrew Cooper wrote:
> Under some circumstances, the migration v2 save code would generate valid
> records with zero content, when the intended behaviour was to omit the record
> entirely.
>
> As the stream is otherwise fine, tolerate these records and avo
Hi George,
On 25/07/16 09:38, George Dunlap wrote:
On Thu, Jul 21, 2016 at 10:15 PM, Stefano Stabellini
wrote:
You are assuming that the guest will map the ACPI blob with the same
attributes as the rest of the superpage.
IHMO, a sane operating system will want to map the ACPI blob read-only.
On 25/07/16 10:34, Wei Liu wrote:
> On Mon, Jul 25, 2016 at 11:30:32AM +0200, Marek Marczykowski-Górecki wrote:
>> On Mon, Jul 25, 2016 at 10:27:47AM +0100, Wei Liu wrote:
>>> On Sun, Jul 24, 2016 at 09:27:13PM +0200, Marek Marczykowski-Górecki wrote:
It is no longer required since xl devd use
On Thu, Jul 21, 2016 at 06:17:36PM +0100, Andrew Cooper wrote:
> It was never intended for records such as these to be sent with zero content.
>
Wouldn't it be better to modify write_split_record to ignore zero
content instead of patching up different places?
> Signed-off-by: Andrew Cooper
> --
On Thu, Jul 21, 2016 at 06:17:37PM +0100, Andrew Cooper wrote:
> These records shouldn't be in a stream, but accidentally are. Warn about
> them, but don't abort the verification.
>
> While here, add a missing length check to the X86_PV_P2M_FRAMES record
> checker.
>
> Signed-off-by: Andrew Coop
On Mon, Jul 25, 2016 at 10:45:54AM +0100, Andrew Cooper wrote:
> On 25/07/16 10:34, Wei Liu wrote:
> > On Mon, Jul 25, 2016 at 11:30:32AM +0200, Marek Marczykowski-Górecki wrote:
> >> On Mon, Jul 25, 2016 at 10:27:47AM +0100, Wei Liu wrote:
> >>> On Sun, Jul 24, 2016 at 09:27:13PM +0200, Marek Marc
Hello,
On 25/07/16 10:04, Sergej Proskurin wrote:
On 07/25/2016 10:32 AM, Wei Liu wrote:
On Sun, Jul 24, 2016 at 06:06:00PM +0200, Sergej Proskurin wrote:
+xc_hvm_param_set(handle, domid, HVM_PARAM_ALTP2M,
+ libxl_defbool_val(info->u.pv.altp2m));
+}
+#endif
+
s
On 25/07/16 10:45, Wei Liu wrote:
> On Thu, Jul 21, 2016 at 06:17:36PM +0100, Andrew Cooper wrote:
>> It was never intended for records such as these to be sent with zero content.
>>
> Wouldn't it be better to modify write_split_record to ignore zero
> content instead of patching up different place
On Mon, Jul 25, 2016 at 10:49:41AM +0100, Julien Grall wrote:
> Hello,
>
> On 25/07/16 10:04, Sergej Proskurin wrote:
> >On 07/25/2016 10:32 AM, Wei Liu wrote:
> >>On Sun, Jul 24, 2016 at 06:06:00PM +0200, Sergej Proskurin wrote:
> >+xc_hvm_param_set(handle, domid, HVM_PARAM_ALTP2M,
>
On Mon, Jul 25, 2016 at 10:57:13AM +0100, Andrew Cooper wrote:
> On 25/07/16 10:45, Wei Liu wrote:
> > On Thu, Jul 21, 2016 at 06:17:36PM +0100, Andrew Cooper wrote:
> >> It was never intended for records such as these to be sent with zero
> >> content.
> >>
> > Wouldn't it be better to modify wri
On 22/07/16 09:50, Sander Eikelenboom wrote:
> Thursday, July 21, 2016, 12:18:37 PM, you wrote:
>
>> c/s 74c6dc2d "x86/vMSI-X: defer intercept handler registration" caused MSI-X
>> table infrastructure not to always be initialised, but it missed one path
>> which needed an is-initialised check.
>>
On 25/07/16 11:16, Andrew Cooper wrote:
> On 22/07/16 09:50, Sander Eikelenboom wrote:
>> Thursday, July 21, 2016, 12:18:37 PM, you wrote:
>>
>>> c/s 74c6dc2d "x86/vMSI-X: defer intercept handler registration" caused MSI-X
>>> table infrastructure not to always be initialised, but it missed one pat
On 21/07/16 18:17, Andrew Cooper wrote:
> The sending side shouldn't send any variable sized records which end up having
> zero content, but the receiving side will need to tolerate such records for
> compatibility purposes.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Ian Jackson
> CC: Wei Liu
On Mon, Jul 25, 2016 at 11:38:20AM +0200, Ingo Jürgensmann wrote:
> On 22.07.2016 12:21, Ingo Jürgensmann wrote:
> >On 22.07.2016 11:03, Ingo Jürgensmann wrote:
> >
> >>In the meanwhile, I activated IPv6 again on Tuesday evening and today
> >>the server crashed again some minutes ago. Here's the ou
Monday, July 25, 2016, 12:19:55 PM, you wrote:
> On 25/07/16 11:16, Andrew Cooper wrote:
>> On 22/07/16 09:50, Sander Eikelenboom wrote:
>>> Thursday, July 21, 2016, 12:18:37 PM, you wrote:
>>>
c/s 74c6dc2d "x86/vMSI-X: defer intercept handler registration" caused
MSI-X
table infr
On 25/07/16 11:21, David Vrabel wrote:
> On 21/07/16 18:17, Andrew Cooper wrote:
>> The sending side shouldn't send any variable sized records which end up
>> having
>> zero content, but the receiving side will need to tolerate such records for
>> compatibility purposes.
>>
>> Signed-off-by: Andre
On Thu, Jul 21, 2016 at 11:18 AM, Andrew Cooper
wrote:
> c/s 74c6dc2d "x86/vMSI-X: defer intercept handler registration" caused MSI-X
> table infrastructure not to always be initialised, but it missed one path
> which needed an is-initialised check.
>
> If a devices is passed through to a domain w
On 07/25/2016 05:20 PM, Roger Pau Monné wrote:
> On Sat, Jul 23, 2016 at 06:18:23AM +0800, Bob Liu wrote:
>>
>> On 07/22/2016 07:45 PM, Roger Pau Monné wrote:
>>> On Fri, Jul 22, 2016 at 05:43:32PM +0800, Bob Liu wrote:
On 07/22/2016 05:34 PM, Roger Pau Monné wrote:
> On Fri, Jul 22,
On 21/07/16 18:17, Andrew Cooper wrote:
> It was never intended for records such as these to be sent with zero content.
As the original author of the specification I'm perhaps best placed to
say what the original intention is.
For records such as HVM_PARAMS which consist of a set of N items, the
On 25/07/16 11:25, Andrew Cooper wrote:
> On 25/07/16 11:21, David Vrabel wrote:
>> On 21/07/16 18:17, Andrew Cooper wrote:
>>> The sending side shouldn't send any variable sized records which end up
>>> having
>>> zero content, but the receiving side will need to tolerate such records for
>>> com
8738d60622c1 "cr-ensure-disk-space: Break out check_space" renamed
iteration_continue to iteration_proceed but did not change the call
site.
Signed-off-by: Ian Jackson
---
cr-ensure-disk-space | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cr-ensure-disk-space b/cr-ensure-di
d221996eea64 "cr-ensure-disk-space: Run check_space before taking
lock" introduced an additional call to check_space but check_space
prints the start of a message (with no newline) expecting
iteration_proceed to print the rest.
Move $|=1 up appropriately and add a couple of messages in the right
p
We are going to want another call site.
No functional change.
Signed-off-by: Ian Jackson
---
cr-ensure-disk-space | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/cr-ensure-disk-space b/cr-ensure-disk-space
index bb98835..6a9781a 100755
--- a/cr-ensure-disk-space
+
On 25/07/16 11:35, David Vrabel wrote:
> On 25/07/16 11:25, Andrew Cooper wrote:
>> On 25/07/16 11:21, David Vrabel wrote:
>>> On 21/07/16 18:17, Andrew Cooper wrote:
The sending side shouldn't send any variable sized records which end up
having
zero content, but the receiving side
> On Mon, Jul 25, 2016 at 11:38:20AM +0200, Ingo Jürgensmann wrote:
>> On 22.07.2016 12:21, Ingo Jürgensmann wrote:
>>> On 22.07.2016 11:03, Ingo Jürgensmann wrote:
>>>
In the meanwhile, I activated IPv6 again on Tuesday evening and today
the server crashed again some minutes ago. Here's
On 25/07/16 11:38, Andrew Cooper wrote:
> On 25/07/16 11:35, David Vrabel wrote:
>> On 25/07/16 11:25, Andrew Cooper wrote:
>>> On 25/07/16 11:21, David Vrabel wrote:
On 21/07/16 18:17, Andrew Cooper wrote:
> The sending side shouldn't send any variable sized records which end up
> ha
On 25/07/16 11:44, David Vrabel wrote:
> On 25/07/16 11:38, Andrew Cooper wrote:
>> On 25/07/16 11:35, David Vrabel wrote:
>>> On 25/07/16 11:25, Andrew Cooper wrote:
On 25/07/16 11:21, David Vrabel wrote:
> On 21/07/16 18:17, Andrew Cooper wrote:
>> The sending side shouldn't send any
On Tue, Jul 12, 2016 at 05:30:40PM +0200, Juergen Gross wrote:
> Add another callback to the device type framework in order to aid
> decision whether a pv domain needs a device model.
>
> Signed-off-by: Juergen Gross
Acked-by: Wei Liu
___
Xen-devel m
On Tue, Jul 12, 2016 at 05:30:39PM +0200, Juergen Gross wrote:
> Instead of using a macro generating the code to merge xenstore and
> json configuration data, use the generic device type support for
> this purpose.
>
> This requires to add some accessor functions to the framework and
> a structure
On Tue, Jul 12, 2016 at 05:30:44PM +0200, Juergen Gross wrote:
> Put all nic related stuff of libxl form common files into a dedicated
> source file.
>
> Signed-off-by: Juergen Gross
Assuming this is pure code motion:
Acked-by: Wei Liu
___
Xen-devel
On Tue, Jul 12, 2016 at 05:30:42PM +0200, Juergen Gross wrote:
> Put all vtpm related stuff of libxl into a dedicated source file.
>
> Signed-off-by: Juergen Gross
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen
On Tue, Jul 12, 2016 at 05:30:41PM +0200, Juergen Gross wrote:
> Outside libxl_pvusb.c only libxl_util.c still contains some pvusb code.
>
> Move it to libxl_pvusb.c.
>
> Signed-off-by: Juergen Gross
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-
On Tue, Jul 12, 2016 at 05:30:43PM +0200, Juergen Gross wrote:
> Some device types require a configuration update after resume of
> domain. Add a callback for this purpose.
>
> Signed-off-by: Juergen Gross
Acked-by: Wei Liu
___
Xen-devel mailing list
On 25/07/16 10:38, Ingo Jürgensmann wrote:
> On 22.07.2016 12:21, Ingo Jürgensmann wrote:
>> On 22.07.2016 11:03, Ingo Jürgensmann wrote:
>>
>>> In the meanwhile, I activated IPv6 again on Tuesday evening and today
>>> the server crashed again some minutes ago. Here's the output from
>>> netconsole
>> Your report and the debian report suggested that Dom0 kernel is less
>> likely to be the culprit because you've tried different Dom0 kernels.
>
> yes we did. but nothing newer than 3.16 so far, we could try that, too.
i have to correct myself:
we also tried 4.4 a while ago, maybe we should try
On Fri, 2016-07-15 at 10:56 -0400, Meng Xu wrote:
> On Fri, Jul 15, 2016 at 8:01 AM, Dario Faggioli
> wrote:
> >
> > * "Consideration of Real Time GPU Scheduling of XenGT in Automotive
> > Embedded System"
> > Sangyun Lee, LG Electronics http://sched.co/7Lh3
> >
> > * "Xenbedded: Xen-based
On Mon, Jul 25, 2016 at 12:42:39PM +0200, Andreas Ziegler wrote:
> > On Mon, Jul 25, 2016 at 11:38:20AM +0200, Ingo Jürgensmann wrote:
> >> On 22.07.2016 12:21, Ingo Jürgensmann wrote:
> >>> On 22.07.2016 11:03, Ingo Jürgensmann wrote:
> >>>
> In the meanwhile, I activated IPv6 again on Tuesda
On Mon, Jul 25, 2016 at 06:29:22PM +0800, Bob Liu wrote:
>
> On 07/25/2016 05:20 PM, Roger Pau Monné wrote:
> > On Sat, Jul 23, 2016 at 06:18:23AM +0800, Bob Liu wrote:
> >>
> >> On 07/22/2016 07:45 PM, Roger Pau Monné wrote:
> >>> On Fri, Jul 22, 2016 at 05:43:32PM +0800, Bob Liu wrote:
>
>
Hi Wei,
On 25/07/16 09:53, Wei Liu wrote:
On Fri, Jul 22, 2016 at 03:27:30AM +, osstest service owner wrote:
flight 97737 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97737/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
On Mon, Jul 25, 2016 at 06:33:35AM +0200, Juergen Gross wrote:
> On 22/07/16 20:51, Wei Liu wrote:
> > On Fri, Jul 22, 2016 at 08:49:17PM +0200, Juergen Gross wrote:
> >> On 22/07/16 18:31, Wei Liu wrote:
> >>> Only skim-read this patch, will do proper review later.
> >>>
> >>> On Fri, Jul 22, 2016
On 07/25/2016 06:53 PM, Roger Pau Monné wrote:
..[snip..]
* We get the device lock and blk_mq_freeze_queue() in
dynamic_reconfig_device(),
and then have to release in blkif_recover() asynchronously which makes
the code more difficult to readable.
>>>
>>> I'm not sure I'm
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 handling of
level 2 page tables (5 days ago)
* 60e06f2 - arm/traps: fix bug in dump_guest_s1_walk L1 page table offset
computation (5
On 18/07/16 11:28, Dario Faggioli wrote:
> On Fri, 2016-07-15 at 19:02 +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
Andrew Cooper writes ("[PATCH 1/4] docs: Clarify the expected behaviour of zero
length records"):
> The sending side shouldn't send any variable sized records which end
> up having zero content, but the receiving side will need to tolerate
> such records for compatibility purposes.
...
> +Some rec
Andrew Cooper writes ("Re: [PATCH XTF 3/3] xtf-runner: regularise runner exit
code"):
> On 22/07/16 10:29, Wei Liu wrote:
> > This would cause a FAILURE to overwrite previous ERROR result. Is that
> > what you want?
>
> When running more than one test, the overall result should be the most
> sev
On 07/25/2016 12:08 PM, Wei Liu wrote:
> On Mon, Jul 25, 2016 at 10:49:41AM +0100, Julien Grall wrote:
>> Hello,
>>
>> On 25/07/16 10:04, Sergej Proskurin wrote:
>>> On 07/25/2016 10:32 AM, Wei Liu wrote:
On Sun, Jul 24, 2016 at 06:06:00PM +0200, Sergej Proskurin wrote:
>>> +xc_hv
On 25.07.2016 12:51, Wei Liu wrote:
[...]
> Your report and the debian report suggested that Dom0 kernel is less
> likely to be the culprit because you've tried different Dom0 kernels.
yes we did. but nothing newer than 3.16 so far, we could try that,
too.
There is a 4.5 backport kernel for Je
Wei Liu writes ("Re: [PATCH] tools/libxc: Properly increment ApicIdCoreSize
field on AMD"):
> On Fri, Jul 22, 2016 at 01:45:05PM -0400, Boris Ostrovsky wrote:
> > On 07/22/2016 01:38 PM, Wei Liu wrote:
> > But this actually fixes a regression that was triggered by recent
> > hvmloader change on on
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 handling of level
2 page tables (5 days ago)
* 60e06f2 - arm/traps: fix bug in dump_guest_s1_walk
On Mon, Jul 25, 2016 at 01:26:29PM +0200, Sergej Proskurin wrote:
>
> On 07/25/2016 12:08 PM, Wei Liu wrote:
> > On Mon, Jul 25, 2016 at 10:49:41AM +0100, Julien Grall wrote:
> >> Hello,
> >>
> >> On 25/07/16 10:04, Sergej Proskurin wrote:
> >>> On 07/25/2016 10:32 AM, Wei Liu wrote:
> On Sun
On 25.07.2016 12:23, Wei Liu wrote:
First, thank you for replying! Very much appreciated! :)
I did skim your emails. But the oops was happening in memcpy+0x6 which
indicated it came back to the origin question why would it got an
exception there.
Just by staring at the code doesn't get me anyw
David Vrabel writes ("Re: [Xen-devel] [PATCH 3/4] tools/libxc: Avoid generating
inappropriate zero-length records"):
> For records such as HVM_PARAMS which consist of a set of N items, the
> intention was to most definitely send a record with 0 items.
>
> For records that fetch an opaque blob fro
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 handling
> >of le
On 25/07/16 12:25, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH XTF 3/3] xtf-runner: regularise runner exit
> code"):
>> On 22/07/16 10:29, Wei Liu wrote:
>>> This would cause a FAILURE to overwrite previous ERROR result. Is that
>>> what you want?
>> When running more than one test, the
On Mon, Jul 25, 2016 at 07:08:36PM +0800, Bob Liu wrote:
>
> On 07/25/2016 06:53 PM, Roger Pau Monné wrote:
> ..[snip..]
> * We get the device lock and blk_mq_freeze_queue() in
> dynamic_reconfig_device(),
> and then have to release in blkif_recover() asynchronously which
> >>
On 21/07/16 18:17, Andrew Cooper wrote:
> Under some circumstances, the migration v2 save code would generate valid
> records with zero content, when the intended behaviour was to omit the record
As explained, this is not the intended behaviour. I wou
On 25/07/16 13:05, Wei Liu wrote:
> On Mon, Jul 25, 2016 at 06:33:35AM +0200, Juergen Gross wrote:
>> On 22/07/16 20:51, Wei Liu wrote:
>>> On Fri, Jul 22, 2016 at 08:49:17PM +0200, Juergen Gross wrote:
On 22/07/16 18:31, Wei Liu wrote:
> Only skim-read this patch, will do proper review la
On 07/25/2016 08:11 PM, Roger Pau Monné wrote:
> On Mon, Jul 25, 2016 at 07:08:36PM +0800, Bob Liu wrote:
>>
>> On 07/25/2016 06:53 PM, Roger Pau Monné wrote:
>> ..[snip..]
>> * We get the device lock and blk_mq_freeze_queue() in
>> dynamic_reconfig_device(),
>>and then have to r
Monday, July 25, 2016, 1:27:20 PM, you wrote:
> On 25.07.2016 12:51, Wei Liu wrote:
>>> [...]
>>> > Your report and the debian report suggested that Dom0 kernel is less
>>> > likely to be the culprit because you've tried different Dom0 kernels.
>>> yes we did. but nothing newer than 3.16 so far,
On 30/06/16 16:56, 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'
On 25/07/16 13:21, David Vrabel wrote:
> On 21/07/16 18:17, Andrew Cooper wrote:
>> Under some circumstances, the migration v2 save code would generate valid
>> records with zero content, when the intended behaviour was to omit the record
>
> As explai
flight 99608 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99608/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 94748
build-i386-xsm
On 25/07/16 13:46, Andrew Cooper wrote:
> On 25/07/16 13:21, David Vrabel wrote:
>> On 21/07/16 18:17, Andrew Cooper wrote:
>>> Under some circumstances, the migration v2 save code would generate valid
>>> records with zero content, when the intended behaviour was to omit the
>>> record
>>
On Mon, Jul 25, 2016 at 01:41:41PM +0200, Ingo Jürgensmann wrote:
> On 25.07.2016 12:23, Wei Liu wrote:
>
> First, thank you for replying! Very much appreciated! :)
>
> >I did skim your emails. But the oops was happening in memcpy+0x6 which
> >indicated it came back to the origin question why wou
Hi David,
On 25/07/16 13:38, David Vrabel wrote:
On 30/06/16 16:56, 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 b
On Mon, Jul 25, 2016 at 10:17:44AM +0100, Wei Liu wrote:
> On Sun, Jul 24, 2016 at 09:26:57PM +0200, Marek Marczykowski-Górecki wrote:
> > Having DefaultDependencies=no means it can be started before / is
> > remounted read-write, which will result in various failures (to start
> > with opening the
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"):
> > On Fri, Jul 22, 2016 at 01:45:05PM -0400, Boris Ostrovsky wrote:
> > > On 07/22/2016 01:38 PM, Wei Liu wrote:
> > > But this actually fix
Hi Luis,
On Fri, 22 Jul 2016 14:24:34 -0700
"Luis R. Rodriguez" wrote:
> This RFC v3 builds off the last RFC v2 series [0] for adding linker tables.
> The largest amount of work here was to take Russell King's feedback on
> using linker table for kprobes text not being appropriate -- and providi
Julien Grall writes:
> Hi David,
>
> On 25/07/16 13:38, David Vrabel wrote:
>> On 30/06/16 16:56, 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 wher
On Sun, Jul 10, 2016 at 02:47:32PM +0300, Emil Condrea wrote:
> The purpose of the new file is to store generic functions shared by frontend
> and backends such as xenstore operations, xendevs.
>
> Signed-off-by: Quan Xu
> Signed-off-by: Emil Condrea
> ---
> hw/xen/Makefile.objs | 2 +
On Fri, Jul 22, 2016 at 05:09:31PM +0200, Juergen Gross wrote:
[...]
> diff --git a/tools/hotplug/Linux/launch-xenstore.in
> b/tools/hotplug/Linux/launch-xenstore.in
> index 2bd9f64..fdfa33a 100644
> --- a/tools/hotplug/Linux/launch-xenstore.in
> +++ b/tools/hotplug/Linux/launch-xenstore.in
> @@ -
On 25/07/16 15:43, Wei Liu wrote:
> On Fri, Jul 22, 2016 at 05:09:31PM +0200, Juergen Gross wrote:
> [...]
>> diff --git a/tools/hotplug/Linux/launch-xenstore.in
>> b/tools/hotplug/Linux/launch-xenstore.in
>> index 2bd9f64..fdfa33a 100644
>> --- a/tools/hotplug/Linux/launch-xenstore.in
>> +++ b/to
On Sun, Jul 10, 2016 at 02:47:38PM +0300, Emil Condrea wrote:
> Prepare xen_be_unbind_evtchn to be shared with frontends:
> * xen_be_unbind_evtchn -> xen_pv_unbind_evtchn
>
> Signed-off-by: Emil Condrea
> ---
> hw/block/xen_disk.c| 2 +-
> hw/char/xen_console.c | 2 +-
> hw/display
On Fri, Jul 22, 2016 at 05:09:29PM +0200, Juergen Gross wrote:
> In order to prepare starting a xenstore domain split out the starting
> of the xenstore daemon from the xencommons script into a dedicated
> launch-xenstore script.
>
> Correct one error: don't remove old tdb files in background, as
On 25/07/16 14:17, Julien Grall wrote:
> Hi David,
>
> On 25/07/16 13:38, David Vrabel wrote:
>> On 30/06/16 16:56, 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
On 07/25/2016 09:32 AM, Masami Hiramatsu wrote:
> I'm not a lawyer, so I don't know really it is compatible with GPLv2,
> and if it is, I'm not sure the reason why we need another license.
> AFAICS the license terms, most of parts looks reasonable. I just concern
> clause 8, after fifteen years, i
On Sun, Jul 10, 2016 at 02:47:33PM +0300, Emil Condrea wrote:
> Its purpose is to store frontend related functions.
>
> Signed-off-by: Quan Xu
> Signed-off-by: Emil Condrea
> ---
> hw/block/xen_disk.c | 1 +
> hw/display/xenfb.c| 1 +
> hw/net/xen_nic.c | 1
On Sun, Jul 10, 2016 at 02:47:39PM +0300, Emil Condrea wrote:
> Prepare xen_be_send_notify to be shared with frontends:
> * xen_be_send_notify -> xen_pv_send_notify
>
> Signed-off-by: Emil Condrea
> ---
> hw/block/xen_disk.c| 4 ++--
> hw/char/xen_console.c | 4 ++--
> hw/display/x
I went back to the long thread in v1. I don't think I can figure out
if all the comments are addressed.
Ian asked for something to be rectified, but I'm not sure if this series
satisfies him. I will let him comment on that.
Wei.
___
Xen-devel mailing l
Hello,
On 25/07/16 14:39, Vitaly Kuznetsov wrote:
Julien Grall writes:
Hi David,
On 25/07/16 13:38, David Vrabel wrote:
On 30/06/16 16:56, 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
On Mon, Jul 25, 2016 at 03:56:17PM +0200, Juergen Gross wrote:
> On 25/07/16 15:43, Wei Liu wrote:
> > On Fri, Jul 22, 2016 at 05:09:31PM +0200, Juergen Gross wrote:
> > [...]
> >> diff --git a/tools/hotplug/Linux/launch-xenstore.in
> >> b/tools/hotplug/Linux/launch-xenstore.in
> >> index 2bd9f64.
On 25/07/16 16:01, Wei Liu wrote:
> On Mon, Jul 25, 2016 at 03:56:17PM +0200, Juergen Gross wrote:
>> On 25/07/16 15:43, Wei Liu wrote:
>>> On Fri, Jul 22, 2016 at 05:09:31PM +0200, Juergen Gross wrote:
>>> [...]
diff --git a/tools/hotplug/Linux/launch-xenstore.in
b/tools/hotplug/Linux/l
1 - 100 of 164 matches
Mail list logo
