Re: [Xen-devel] [PATCH v4 3/4] libxl: add HVM usb passthrough support
On 20/09/16 15:18, Juergen Gross wrote: > Add HVM usb passthrough support to libxl by using qemu's capability > to emulate standard USB controllers. > > A USB controller is added via qmp command to the emulated hardware > when a usbctrl device of type DEVICEMODEL is requested. Depending on > the requested speed the appropriate hardware type is selected. A host > USB device can then be added to the emulated USB controller via qmp > command. > > Removing of the devices is done via qmp commands, too. > > Signed-off-by: Juergen Gross > Acked-by: Wei Liu Acked-by: George Dunlap ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues
On 9/19/2016 10:46 PM, Jan Beulich wrote: Well, without a clear understanding of why the issue occurs (for >> which I need to refer you back to the questionable stack dump) >> I'm hesitant to agree to this step, yet ... > > After some researches, I found do_invalid_op() on the stack dump is > caused by run_in_exception_handler(__ns16550_poll) in the ns16550_poll() > rather than fatal event. The timeout issue still exists when run > __ns16550_poll() directly in the ns16550_poll(). Well, I then still don't see why e.g. dump_domains() doesn't also need it. After testing, dump_domains() also has such issue after I create two VM with 128 vcpus. Earlier you did say: Keyhandler may run in the timer handler and the following log shows calltrace. The timer subsystem run all expired timers' handler before programing next timer event. If keyhandler runs longer than timeout, there will be no chance to configure timer before triggering watchdog and hypervisor rebooting. The fact that using debug keys may adversely affect the rest of the system is known. And the nesting of process_pending_softirqs() inside do_softirq() should, from looking at them, work fine. So I continue to have trouble seeing the specific reason for the problem you say you observe. The precondition of process_pending_softirq() working in the debug key handler is that timer interrupt arrives on time and nmi_timer_fn() can run to update nmi_timer_ticks before watchdog timeout. When a timer interrupt arrives, timer_softirq_action() will run all expired timer handlers before programing next timer interrupt via reprogram_timer(). If a timer handler runs too long E,G >5s(Time for watchdog timeout is default to be 5s.), this will cause no timer interrupt arriving within 5s and nmi_timer_fn() also won't be called. Does this make sense to you? And as a separate note - dump_registers() is quite an exception among the key handlers, and that's for a good reason (as the comment there says). So I continue to be hesitant to see this spread to other key handlers. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 2/2] xen: move TLB-flush filtering out into populate_physmap during vm creation
On Tue, Sep 20, 2016 at 10:31:04AM +0800, Dongli Zhang wrote: > This patch implemented parts of TODO left in commit id > a902c12ee45fc9389eb8fe54eeddaf267a555c58 (More efficient TLB-flush > filtering in alloc_heap_pages()). It moved TLB-flush filtering out into > populate_physmap. Because of TLB-flush in alloc_heap_pages, it's very slow > to create a guest with memory size of more than 100GB on host with 100+ > cpus. > Do you have some actual numbers on how much faster after applying this patch? This is mostly for writing release note etc, so it is fine if you don't have numbers at hand. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 02/21] acpi: Prevent GPL-only code from seeping into non-GPL binaries
On 09/20/2016 10:19 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [PATCH v4 02/21] acpi: Prevent GPL-only code
> from seeping into non-GPL binaries"):
>> But yes, I can split dsdt.asl as well. Should we keep _S5 definition as
>> GPL-only?
> I think once we're going down this route there is no benefit in trying
> to argue for individual bits of code-that-was-once-Lenovo's that there
> is no copyright interest.
>
> So I would split those lines out as well. That will mean multiple
> includes.
>
> Does iasl have a suitable conditional include syntax or are you going
> to use `cat' or something in the Makefile ?
iasl has -I option but I don't see a conditional. (And I have very
vague understanding of ASL syntax in case there is something that can be
done in the language itself).
I ran a quick test with 'cat' and it seems to work OK. Besides, we are
already using 'cat' implicitly: we append mk_dsdt output to existing
*asl file.
-boris
signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation
On Tue, Sep 20, 2016 at 1:26 AM, Jan Beulich wrote:
On 19.09.16 at 20:27, wrote:
>> On Mon, Sep 19, 2016 at 2:19 AM, Jan Beulich wrote:
>> On 15.09.16 at 18:51, wrote:
@@ -1793,7 +1793,17 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt
>> *hvmemul_ctxt,
pfec |= PFEC_user_mode;
hvmemul_ctxt->insn_buf_eip = regs->eip;
-if ( !vio->mmio_insn_bytes )
+
+if ( unlikely(hvmemul_ctxt->set_context_insn) && curr->arch.vm_event )
+{
+BUILD_BUG_ON(sizeof(hvmemul_ctxt->insn_buf_bytes) ==
+ sizeof(curr->arch.vm_event->emul.insn));
>>>
>>> This should quite clearly be !=, and I think it builds only because you
>>> use the wrong operand in the first sizeof().
>>>
+hvmemul_ctxt->insn_buf_bytes =
sizeof(curr->arch.vm_event->emul.insn);
+memcpy(hvmemul_ctxt->insn_buf, &curr->arch.vm_event->emul.insn,
+ hvmemul_ctxt->insn_buf_bytes);
>>>
>>> This memcpy()s between dissimilar types. Please omit the & and
>>> properly add .data on the second argument (and this .data
>>> addition should then also be mirrored in the BUILD_BUG_ON()).
>>>
+}
+else if ( !vio->mmio_insn_bytes )
>>>
>>> And then - I'm sorry for not having thought of this before - I think
>>> this would better not live here, or have an effect more explicitly
>>> only when coming here through hvm_emulate_one_vm_event().
>>> Since the former seems impractical, I think giving _hvm_emulate_one()
>>> one or two extra parameters would be the most straightforward
>>> approach.
>>
>> So this is the spot where the mmio insn buffer is getting copied as
>> well instead of fetching the instructions from the guest memory. So
>> having the vm_event buffer getting copied here too makes the most
>> sense. Having the vm_event insn buffer getting copied in somewhere
>> else, while the mmio insn buffer getting copied here, IMHO just
>> fragments the flow even more making it harder to see what is actually
>> happening.
>
> And I didn't unconditionally ask to move the copying elsewhere.
> The alternative - passing the override in as function argument(s),
> which would then be NULL/zero for all cases except the VM event
> one, would be as suitable. It is in particular ...
>
>> How about adjusting the if-else here to be:
>>
>> if ( !vio->mmio_insn_bytes && !hvmemul_ctxt->set_context_insn )
>> ...
>> else if ( vio->mmio_insn_bytes )
>> ...
>> else if ( unlikely(hvmemul_ctxt->set_context_insn) && curr->arch.vm_event )
>
> ... this curr->arch.vm_event reference which I'd like to see gone
> from this specific code path. The ordering in your original patch,
> otoh, would then be fine (check for the override first with unlikely(),
> else do what is being done today). Such a code structure would
> then also ease a possible second way of overriding the insn by
> some other party, without having to touch the code here again.
>
So that check is one that Razvan asked to be added. I think it is
necessary too as there seems to be a race-condition if vm_event gets
shutdown after the response flag is set but before this emulation path
takes place. Effectively set_context_insn may be set but the
arch.vm_event already gotten freed. Razvan, is that correct?
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [ovmf baseline-only test] 67733: all pass
This run is configured for baseline tests only. flight 67733 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67733/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 0a92ac8802704d7281ff7b9bc00ec4f893c3ece2 baseline version: ovmf 490acf8908f797982f367bfeb4bdf3ebe0764e42 Last test of basis67720 2016-09-15 17:19:47 Z4 days Testing same since67733 2016-09-20 11:46:17 Z0 days1 attempts People who touched revisions under test: Hegde Nagaraj P Jiaxin Wu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 0a92ac8802704d7281ff7b9bc00ec4f893c3ece2 Author: Jiaxin Wu Date: Wed Sep 14 14:43:45 2016 +0800 NetworkPkg: Correct the DNS token return status by RCODE When HostNameToIp() and GeneralLookUp() are called with a invalid host name, RCODE (4 bit field is set as part of responses) error will returned in packet to identify the domain name referenced in the query does not exist. So, EFI_NOT_FOUND should be returned directly. Current implementation only check the RCODE in successful condition. Need update the code for more error check according to RFC 1035 4.1.1 section. Cc: Hegde Nagaraj P Cc: Fu Siyuan Cc: Ye Ting Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiaxin Wu Tested-by: Hegde Nagaraj P Reviewed-by: Sriram Subramanian ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 0/4] libxl: add HVM USB passthrough capability
On Tue, Sep 20, 2016 at 04:18:06PM +0200, Juergen Gross wrote: > Add the capability to pass USB devices to HVM domains by using the > emulation of USB controllers of qemu. > > The user interface via xl is the same as for pvusb passthrough, only > the type of the usbctrl is different: instead of "qusb" (qemu-based > pvusb backend) or "vusb" (kernel-based pvusb backend) the type > "devicemodel" is used. > > Especially the communication with qemu via qmp commands is based on > the patches of George Dunlap sent in 2014: > > https://lists.xen.org/archives/html/xen-devel/2014-06/msg00085.html > > Changes in V4: > - patch 2: corrected libxl__device_destroy() to not use be_path being NULL > > Changes in V3: > - patch 3: rename pvusb_get_port_path() to vusb_get_port_path() > as requested by George Dunlap > - patch 4: wording adjusted as requested by Ian Jackson > > Changes in V2: > - patches 1-3 removed as already pushed > - split out (new) patch 1 from patch 3 (was 5) as requested by Wei Liu > - addressed code style issues in patch 3 (was 5) as requested by Wei Liu > - added some assert()s n patch 3 (was 5) as requested by Wei Liu > > Juergen Gross (4): > libxl: add function to remove usb controller xenstore entries > libxl: add basic support for devices without backend > libxl: add HVM usb passthrough support > docs: add HVM USB passthrough documentation > > docs/man/xl.cfg.pod.5.in | 12 +- > tools/libxl/libxl_device.c | 73 -- > tools/libxl/libxl_types_internal.idl | 1 + > tools/libxl/libxl_usb.c | 435 > +++ > tools/libxl/libxl_xshelp.c | 6 +- > tools/libxl/xl_cmdimpl.c | 4 +- > 6 files changed, 409 insertions(+), 122 deletions(-) > Series pushed. > -- > 2.6.6 > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation
On 09/20/2016 05:56 PM, Tamas K Lengyel wrote:
> On Tue, Sep 20, 2016 at 1:26 AM, Jan Beulich wrote:
> On 19.09.16 at 20:27, wrote:
>>> On Mon, Sep 19, 2016 at 2:19 AM, Jan Beulich wrote:
>>> On 15.09.16 at 18:51, wrote:
> @@ -1793,7 +1793,17 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt
>>> *hvmemul_ctxt,
> pfec |= PFEC_user_mode;
>
> hvmemul_ctxt->insn_buf_eip = regs->eip;
> -if ( !vio->mmio_insn_bytes )
> +
> +if ( unlikely(hvmemul_ctxt->set_context_insn) && curr->arch.vm_event
> )
> +{
> +BUILD_BUG_ON(sizeof(hvmemul_ctxt->insn_buf_bytes) ==
> + sizeof(curr->arch.vm_event->emul.insn));
This should quite clearly be !=, and I think it builds only because you
use the wrong operand in the first sizeof().
> +hvmemul_ctxt->insn_buf_bytes =
> sizeof(curr->arch.vm_event->emul.insn);
> +memcpy(hvmemul_ctxt->insn_buf, &curr->arch.vm_event->emul.insn,
> + hvmemul_ctxt->insn_buf_bytes);
This memcpy()s between dissimilar types. Please omit the & and
properly add .data on the second argument (and this .data
addition should then also be mirrored in the BUILD_BUG_ON()).
> +}
> +else if ( !vio->mmio_insn_bytes )
And then - I'm sorry for not having thought of this before - I think
this would better not live here, or have an effect more explicitly
only when coming here through hvm_emulate_one_vm_event().
Since the former seems impractical, I think giving _hvm_emulate_one()
one or two extra parameters would be the most straightforward
approach.
>>>
>>> So this is the spot where the mmio insn buffer is getting copied as
>>> well instead of fetching the instructions from the guest memory. So
>>> having the vm_event buffer getting copied here too makes the most
>>> sense. Having the vm_event insn buffer getting copied in somewhere
>>> else, while the mmio insn buffer getting copied here, IMHO just
>>> fragments the flow even more making it harder to see what is actually
>>> happening.
>>
>> And I didn't unconditionally ask to move the copying elsewhere.
>> The alternative - passing the override in as function argument(s),
>> which would then be NULL/zero for all cases except the VM event
>> one, would be as suitable. It is in particular ...
>>
>>> How about adjusting the if-else here to be:
>>>
>>> if ( !vio->mmio_insn_bytes && !hvmemul_ctxt->set_context_insn )
>>> ...
>>> else if ( vio->mmio_insn_bytes )
>>> ...
>>> else if ( unlikely(hvmemul_ctxt->set_context_insn) && curr->arch.vm_event )
>>
>> ... this curr->arch.vm_event reference which I'd like to see gone
>> from this specific code path. The ordering in your original patch,
>> otoh, would then be fine (check for the override first with unlikely(),
>> else do what is being done today). Such a code structure would
>> then also ease a possible second way of overriding the insn by
>> some other party, without having to touch the code here again.
>>
>
> So that check is one that Razvan asked to be added. I think it is
> necessary too as there seems to be a race-condition if vm_event gets
> shutdown after the response flag is set but before this emulation path
> takes place. Effectively set_context_insn may be set but the
> arch.vm_event already gotten freed. Razvan, is that correct?
Yes, that's the general idea, but there's also already a check in
hvm_do_resume() right before calling hvm_mem_access_emulate_one(), so as
long as that's the only code path leading here it should be alright to
remove the check. The check adds extra safety but it's not strictly
necessary here, so if Jan prefers it taken out it should, theoretically,
be fine for now.
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 13/24] libxc: improve error handling of xc Credit1 and Credit2 helpers
On Wed, Aug 17, 2016 at 07:19:04PM +0200, Dario Faggioli wrote: > In fact, libxc wrappers should, on error, set errno and > return -1. > > Signed-off-by: Dario Faggioli Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation
>>> On 20.09.16 at 16:56, wrote:
> On Tue, Sep 20, 2016 at 1:26 AM, Jan Beulich wrote:
> On 19.09.16 at 20:27, wrote:
>>> On Mon, Sep 19, 2016 at 2:19 AM, Jan Beulich wrote:
>>> On 15.09.16 at 18:51, wrote:
> @@ -1793,7 +1793,17 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt
>>> *hvmemul_ctxt,
> pfec |= PFEC_user_mode;
>
> hvmemul_ctxt->insn_buf_eip = regs->eip;
> -if ( !vio->mmio_insn_bytes )
> +
> +if ( unlikely(hvmemul_ctxt->set_context_insn) && curr->arch.vm_event
> )
> +{
> +BUILD_BUG_ON(sizeof(hvmemul_ctxt->insn_buf_bytes) ==
> + sizeof(curr->arch.vm_event->emul.insn));
This should quite clearly be !=, and I think it builds only because you
use the wrong operand in the first sizeof().
> +hvmemul_ctxt->insn_buf_bytes =
> sizeof(curr->arch.vm_event->emul.insn);
> +memcpy(hvmemul_ctxt->insn_buf, &curr->arch.vm_event->emul.insn,
> + hvmemul_ctxt->insn_buf_bytes);
This memcpy()s between dissimilar types. Please omit the & and
properly add .data on the second argument (and this .data
addition should then also be mirrored in the BUILD_BUG_ON()).
> +}
> +else if ( !vio->mmio_insn_bytes )
And then - I'm sorry for not having thought of this before - I think
this would better not live here, or have an effect more explicitly
only when coming here through hvm_emulate_one_vm_event().
Since the former seems impractical, I think giving _hvm_emulate_one()
one or two extra parameters would be the most straightforward
approach.
>>>
>>> So this is the spot where the mmio insn buffer is getting copied as
>>> well instead of fetching the instructions from the guest memory. So
>>> having the vm_event buffer getting copied here too makes the most
>>> sense. Having the vm_event insn buffer getting copied in somewhere
>>> else, while the mmio insn buffer getting copied here, IMHO just
>>> fragments the flow even more making it harder to see what is actually
>>> happening.
>>
>> And I didn't unconditionally ask to move the copying elsewhere.
>> The alternative - passing the override in as function argument(s),
>> which would then be NULL/zero for all cases except the VM event
>> one, would be as suitable. It is in particular ...
>>
>>> How about adjusting the if-else here to be:
>>>
>>> if ( !vio->mmio_insn_bytes && !hvmemul_ctxt->set_context_insn )
>>> ...
>>> else if ( vio->mmio_insn_bytes )
>>> ...
>>> else if ( unlikely(hvmemul_ctxt->set_context_insn) && curr->arch.vm_event )
>>
>> ... this curr->arch.vm_event reference which I'd like to see gone
>> from this specific code path. The ordering in your original patch,
>> otoh, would then be fine (check for the override first with unlikely(),
>> else do what is being done today). Such a code structure would
>> then also ease a possible second way of overriding the insn by
>> some other party, without having to touch the code here again.
>
> So that check is one that Razvan asked to be added. I think it is
> necessary too as there seems to be a race-condition if vm_event gets
> shutdown after the response flag is set but before this emulation path
> takes place. Effectively set_context_insn may be set but the
> arch.vm_event already gotten freed. Razvan, is that correct?
Well, in case you misunderstood: I didn't ask for the check to be
_removed_, but for it to be _moved elsewhere_.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation
On Tue, Sep 20, 2016 at 9:12 AM, Jan Beulich wrote:
On 20.09.16 at 16:56, wrote:
>> On Tue, Sep 20, 2016 at 1:26 AM, Jan Beulich wrote:
>> On 19.09.16 at 20:27, wrote:
On Mon, Sep 19, 2016 at 2:19 AM, Jan Beulich wrote:
On 15.09.16 at 18:51, wrote:
>> @@ -1793,7 +1793,17 @@ static int _hvm_emulate_one(struct
>> hvm_emulate_ctxt
*hvmemul_ctxt,
>> pfec |= PFEC_user_mode;
>>
>> hvmemul_ctxt->insn_buf_eip = regs->eip;
>> -if ( !vio->mmio_insn_bytes )
>> +
>> +if ( unlikely(hvmemul_ctxt->set_context_insn) &&
>> curr->arch.vm_event )
>> +{
>> +BUILD_BUG_ON(sizeof(hvmemul_ctxt->insn_buf_bytes) ==
>> + sizeof(curr->arch.vm_event->emul.insn));
>
> This should quite clearly be !=, and I think it builds only because you
> use the wrong operand in the first sizeof().
>
>> +hvmemul_ctxt->insn_buf_bytes =
>> sizeof(curr->arch.vm_event->emul.insn);
>> +memcpy(hvmemul_ctxt->insn_buf, &curr->arch.vm_event->emul.insn,
>> + hvmemul_ctxt->insn_buf_bytes);
>
> This memcpy()s between dissimilar types. Please omit the & and
> properly add .data on the second argument (and this .data
> addition should then also be mirrored in the BUILD_BUG_ON()).
>
>> +}
>> +else if ( !vio->mmio_insn_bytes )
>
> And then - I'm sorry for not having thought of this before - I think
> this would better not live here, or have an effect more explicitly
> only when coming here through hvm_emulate_one_vm_event().
> Since the former seems impractical, I think giving _hvm_emulate_one()
> one or two extra parameters would be the most straightforward
> approach.
So this is the spot where the mmio insn buffer is getting copied as
well instead of fetching the instructions from the guest memory. So
having the vm_event buffer getting copied here too makes the most
sense. Having the vm_event insn buffer getting copied in somewhere
else, while the mmio insn buffer getting copied here, IMHO just
fragments the flow even more making it harder to see what is actually
happening.
>>>
>>> And I didn't unconditionally ask to move the copying elsewhere.
>>> The alternative - passing the override in as function argument(s),
>>> which would then be NULL/zero for all cases except the VM event
>>> one, would be as suitable. It is in particular ...
>>>
How about adjusting the if-else here to be:
if ( !vio->mmio_insn_bytes && !hvmemul_ctxt->set_context_insn )
...
else if ( vio->mmio_insn_bytes )
...
else if ( unlikely(hvmemul_ctxt->set_context_insn) && curr->arch.vm_event )
>>>
>>> ... this curr->arch.vm_event reference which I'd like to see gone
>>> from this specific code path. The ordering in your original patch,
>>> otoh, would then be fine (check for the override first with unlikely(),
>>> else do what is being done today). Such a code structure would
>>> then also ease a possible second way of overriding the insn by
>>> some other party, without having to touch the code here again.
>>
>> So that check is one that Razvan asked to be added. I think it is
>> necessary too as there seems to be a race-condition if vm_event gets
>> shutdown after the response flag is set but before this emulation path
>> takes place. Effectively set_context_insn may be set but the
>> arch.vm_event already gotten freed. Razvan, is that correct?
>
> Well, in case you misunderstood: I didn't ask for the check to be
> _removed_, but for it to be _moved elsewhere_.
>
So as Razvan pointed out, there is a check already in hvm_do_resume
for exactly the same effect, so then what you are asking for is
already done.
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] New Outreachy Applicant
On Wed, Sep 14, 2016 at 7:35 AM, Ronald Rojas wrote:
> Hi, I'm Ronald Rojas an undergraduate junior studying
> computer science at New York Unversity. I would like
> to apply fo the Xen projects Outreachy Program. After
> looking through the available projects I think I would
> be a good fit for creating the golang bindings for
> libxl. I'm proficient in C , familar with Golang, and
> very comfortable with linux. Would I be able to get a
> bit-sized task for the application process?
Ronald,
Thanks for your interest in the Xen Project! Sorry for the delay in
responding -- somehow your mail either never made it to my personal
inbox or I accidentally deleted it instead of filing it properly. I
saw your question on IRC and now found your mail here on xen-devel.
First, I want to emphasize that Outreachy internships should be
considered a full-time job. As part of the application process you
will be asked to confirm that you will not be taking any classes, nor
have any other significant commitments (such as another job) during
the period of the internship.
Now on to the bite-sized task. We've actually found that one of the
difficult parts of getting going with our project is making sure that
you understand how to get your whole system and environment set up.
And another thing we want to see is to what degree you can balance
figuring things out, finding the answers on the web, and asking for
help when you need it.
So with that in mind, we've started experimenting with tasks which
don't contribute very much to the project directly, but provide a
really solid base of knowledge to do further contributions.
So here's my challenge for you.
---
OUTCOME
Attached is the very beginnings of a set of golang bindings that I
wrote for a project of my own. They contain an implementation of
Context.Open() and Context.ListCpupool().
Write a simple go program that will list the current cpu pools,
similar to the output of "xl cpupool-list". No need to handle extra
arguments or modify libxl.go (beyond what may be needed to compile it).
Please post a copy of your .go program, along with the results of
output *when more than one VM is running*.
STEPS
1. Set up a system running Linux
If you don't have one, Ubuntu, Fedora, or Debian should all be fine.
2. Download, build, and install the latest development
version of Xen. The following page should be useful:
https://wiki.xenproject.org/wiki/Compiling_Xen_From_Source
I would recommend using "make debball" or "make rpmball" over the
"make install".
3. You'll need to build an image for at least one guest VM.
There are tons of options here, but one really simple thing would be
to follow this HOWTO from a previous OPW intern:
https://umasharma17.wordpress.com/2015/02/13/creating-guests-using-xl-in-xen/
4. Write your go program
The go program will need to Open() the context, then call DomainInfo()
on the target domain ID, and output the required info based on "xl
list".
libxl.go uses cgo to compile a library against C. If you have the
libraries set up properly, the current version should just work.
--
That's it! Remember that the goal of this is to see how well you
balance figuring things out on your own vs asking questions. So try
to figure things out on your own, but when you run into a bit of
difficultly, don't hesitate to ask questions or clarification --
particularly at the beginning.
You can ask questions either here on xen-devel or on the #xendevel or
#xen-opw channels on freenode IRC.
Good luck,
-George
/*
* Copyright (C) 2016 George W. Dunlap, Citrix Systems UK Ltd
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; version 2 of the
* License only.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
* 02110-1301, USA.
*/
package main
/*
#cgo LDFLAGS: -lyajl -lxenlight
#include
#include
*/
import "C"
import (
"unsafe"
"fmt"
"time"
)
type Context struct {
ctx *C.libxl_ctx
}
var Ctx Context
func (Ctx *Context) IsOpen() bool {
return Ctx.ctx != nil
}
func (Ctx *Context) Open() (err error) {
if Ctx.ctx != nil {
return
}
ret := C.libxl_ctx_alloc(unsafe.Pointer(&Ctx.ctx), C.LIBXL_VERSION, 0, nil)
if ret != 0 {
err = fmt.Errorf("Allocating libxl context: %d", ret)
}
return
}
func (Ctx *Context) Close() (err error) {
ret := C.libxl_ctx_free(unsafe.Pointer(Ctx.ctx))
Ctx.ctx = nil
if ret != 0 {
err = fmt.Errorf("Freeing libxl context: %d", ret)
}
return
}
type Domid uint32
type MemKB uint64
Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation
On Mon, Sep 19, 2016 at 6:36 PM, Tian, Kevin wrote: >> From: Tamas K Lengyel >> Sent: Tuesday, September 20, 2016 12:40 AM >> >> >> --- a/xen/arch/x86/hvm/hvm.c >> >> +++ b/xen/arch/x86/hvm/hvm.c >> >> @@ -489,13 +489,16 @@ void hvm_do_resume(struct vcpu *v) >> >> >> >> if ( v->arch.vm_event->emulate_flags & >> >> VM_EVENT_FLAG_SET_EMUL_READ_DATA ) >> >> -kind = EMUL_KIND_SET_CONTEXT; >> >> +kind = EMUL_KIND_SET_CONTEXT_DATA; >> >> else if ( v->arch.vm_event->emulate_flags & >> >>VM_EVENT_FLAG_EMULATE_NOWRITE ) >> >> kind = EMUL_KIND_NOWRITE; >> >> +else if ( v->arch.vm_event->emulate_flags & >> >> + VM_EVENT_FLAG_SET_EMUL_INSN_DATA ) >> >> +kind = EMUL_KIND_SET_CONTEXT_INSN; >> > >> > The header talking about incompatibilities between these flags - >> > wouldn't it be a good idea to actually -EINVAL such combinations? >> >> The header just points out that setting all these flags at the same >> time won't have a "combined" effect - evident from the if-else >> treatment above. There is really no point to do an error, the error >> would never reach the user. Setting response flags through vm_event >> doesn't have an error-path back. >> > > Maybe you can have an explicit comment on priority of those flags, > so consistent behavior can be expected moving forward. e.g. above > code implies read_data>nowrite>insn_data. w/o a proper guidance > here, future code changes by others may break that sequence... > Fair point, will do that. Thanks, Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC
Hi,
On 20/09/2016 12:27, George Dunlap wrote:
On Tue, Sep 20, 2016 at 11:03 AM, Peng Fan wrote:
On Tue, Sep 20, 2016 at 02:54:06AM +0200, Dario Faggioli wrote:
On Mon, 2016-09-19 at 17:01 -0700, Stefano Stabellini wrote:
On Tue, 20 Sep 2016, Dario Faggioli wrote:
I'd like to add a computing capability in xen/arm, like this:
struct compute_capatiliby
{
char *core_name;
uint32_t rank;
uint32_t cpu_partnum;
};
struct compute_capatiliby cc=
{
{"A72", 4, 0xd08},
{"A57", 3, 0},
{"A53", 2, 0xd03},
{"A35", 1, ...},
}
Then when identify cpu, we decide which cpu is big and which cpu is little
according to the computing rank.
Any comments?
I think we definitely need to have Xen have some kind of idea the
order between processors, so that the user doesn't need to figure out
which class / pool is big and which pool is LITTLE. Whether this sort
of enumeration is the best way to do that I'll let Julien and Stefano
give their opinion.
I don't think an hardcoded list of processor in Xen is the right
solution. There are many existing processors and combinations for
big.LITTLE so it will nearly be impossible to keep updated.
I would expect the firmware table (device tree, ACPI) to provide
relevant data for each processor and differentiate big from LITTLE core.
Note that I haven't looked at it for now. A good place to start is
looking at how Linux does.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues
>>> On 20.09.16 at 16:52, wrote: > On 9/19/2016 10:46 PM, Jan Beulich wrote: Well, without a clear understanding of why the issue occurs (for >> which I need to refer you back to the questionable stack dump) >> I'm hesitant to agree to this step, yet ... >>> > >>> > After some researches, I found do_invalid_op() on the stack dump is >>> > caused by run_in_exception_handler(__ns16550_poll) in the ns16550_poll() >>> > rather than fatal event. The timeout issue still exists when run >>> > __ns16550_poll() directly in the ns16550_poll(). >> Well, I then still don't see why e.g. dump_domains() doesn't also need >> it. > > After testing, dump_domains() also has such issue after I create two VM > with 128 vcpus. > >> Earlier you did say: >> >> Keyhandler may run in the timer handler and the following log shows >> calltrace. The timer subsystem run all expired timers' handler >> before programing next timer event. If keyhandler runs longer than >> timeout, there will be no chance to configure timer before triggering >> watchdog and hypervisor rebooting. >> >> The fact that using debug keys may adversely affect the rest of the >> system is known. And the nesting of process_pending_softirqs() >> inside do_softirq() should, from looking at them, work fine. So I >> continue to have trouble seeing the specific reason for the problem >> you say you observe. > > The precondition of process_pending_softirq() working in the debug key > handler is that timer interrupt arrives on time and nmi_timer_fn() can > run to update nmi_timer_ticks before watchdog timeout. Precondition? > When a timer interrupt arrives, timer_softirq_action() will run all > expired timer handlers before programing next timer interrupt via > reprogram_timer(). If a timer handler runs too long E,G >5s(Time for > watchdog timeout is default to be 5s.), this will cause no timer > interrupt arriving within 5s and nmi_timer_fn() also won't be called. > Does this make sense to you? Partly. I continue to think that the sequence some keyhandler timer interrupt keyhandler continues keyhandler calls process_pending_softirq() should, among other things, result in timer_softirq_action() to get run. And I don't see the _timer_ handler running for to long here, only a key handler. Are you perhaps instead suffering from the nested instance of timer_softirq_action() not being able to acquire its lock? That would be an entirely different issue than you had described so far. And irrespective of this it is of course quite clear that timers aren't meant to run heavyweight work like key handlers, so the way ns16550_poll() works right now is probably what we'll want to alter. Which btw raises another question: Why are you in polling mode in the first place? Do you have a UART without working interrupt? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation
>>> On 20.09.16 at 17:14, wrote:
> On Tue, Sep 20, 2016 at 9:12 AM, Jan Beulich wrote:
> On 20.09.16 at 16:56, wrote:
>>> On Tue, Sep 20, 2016 at 1:26 AM, Jan Beulich wrote:
>>> On 19.09.16 at 20:27, wrote:
> On Mon, Sep 19, 2016 at 2:19 AM, Jan Beulich wrote:
> On 15.09.16 at 18:51, wrote:
>>> @@ -1793,7 +1793,17 @@ static int _hvm_emulate_one(struct
>>> hvm_emulate_ctxt
> *hvmemul_ctxt,
>>> pfec |= PFEC_user_mode;
>>>
>>> hvmemul_ctxt->insn_buf_eip = regs->eip;
>>> -if ( !vio->mmio_insn_bytes )
>>> +
>>> +if ( unlikely(hvmemul_ctxt->set_context_insn) &&
>>> curr->arch.vm_event )
>>> +{
>>> +BUILD_BUG_ON(sizeof(hvmemul_ctxt->insn_buf_bytes) ==
>>> + sizeof(curr->arch.vm_event->emul.insn));
>>
>> This should quite clearly be !=, and I think it builds only because you
>> use the wrong operand in the first sizeof().
>>
>>> +hvmemul_ctxt->insn_buf_bytes =
>>> sizeof(curr->arch.vm_event->emul.insn);
>>> +memcpy(hvmemul_ctxt->insn_buf, &curr->arch.vm_event->emul.insn,
>>> + hvmemul_ctxt->insn_buf_bytes);
>>
>> This memcpy()s between dissimilar types. Please omit the & and
>> properly add .data on the second argument (and this .data
>> addition should then also be mirrored in the BUILD_BUG_ON()).
>>
>>> +}
>>> +else if ( !vio->mmio_insn_bytes )
>>
>> And then - I'm sorry for not having thought of this before - I think
>> this would better not live here, or have an effect more explicitly
>> only when coming here through hvm_emulate_one_vm_event().
>> Since the former seems impractical, I think giving _hvm_emulate_one()
>> one or two extra parameters would be the most straightforward
>> approach.
>
> So this is the spot where the mmio insn buffer is getting copied as
> well instead of fetching the instructions from the guest memory. So
> having the vm_event buffer getting copied here too makes the most
> sense. Having the vm_event insn buffer getting copied in somewhere
> else, while the mmio insn buffer getting copied here, IMHO just
> fragments the flow even more making it harder to see what is actually
> happening.
And I didn't unconditionally ask to move the copying elsewhere.
The alternative - passing the override in as function argument(s),
which would then be NULL/zero for all cases except the VM event
one, would be as suitable. It is in particular ...
> How about adjusting the if-else here to be:
>
> if ( !vio->mmio_insn_bytes && !hvmemul_ctxt->set_context_insn )
> ...
> else if ( vio->mmio_insn_bytes )
> ...
> else if ( unlikely(hvmemul_ctxt->set_context_insn) && curr->arch.vm_event
> )
... this curr->arch.vm_event reference which I'd like to see gone
from this specific code path. The ordering in your original patch,
otoh, would then be fine (check for the override first with unlikely(),
else do what is being done today). Such a code structure would
then also ease a possible second way of overriding the insn by
some other party, without having to touch the code here again.
>>>
>>> So that check is one that Razvan asked to be added. I think it is
>>> necessary too as there seems to be a race-condition if vm_event gets
>>> shutdown after the response flag is set but before this emulation path
>>> takes place. Effectively set_context_insn may be set but the
>>> arch.vm_event already gotten freed. Razvan, is that correct?
>>
>> Well, in case you misunderstood: I didn't ask for the check to be
>> _removed_, but for it to be _moved elsewhere_.
>>
>
> So as Razvan pointed out, there is a check already in hvm_do_resume
> for exactly the same effect, so then what you are asking for is
> already done.
Partly - I really meant all curr->arch.vm_event uses to go away from
that path. The other part (passing in the override buffer instead of
special casing vm-event handling here) still would need to be done.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-4.6-testing test] 101026: tolerable FAIL - PUSHED
flight 101026 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/101026/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail in 101016 pass in 101026 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail in 101016 pass in 101026 test-armhf-armhf-xl 16 guest-start.2 fail pass in 101016 test-armhf-armhf-xl-cubietruck 16 guest-start.2fail pass in 101016 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 101016 like 100957 test-armhf-armhf-xl-rtds 11 guest-start fail like 100907 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100957 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100957 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100957 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100957 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds12 migrate-support-check fail in 101016 never pass test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 101016 never pass build-amd64-rumprun 5 rumprun-buildfail never pass build-i386-rumprun5 rumprun-buildfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass version targeted for testing: xen 57dbc55cd3e239ab0ce5bdd62cf309e27fe52a1a baseline version: xen 3cffa34537767dfdb6a0fa02c1a54fdfc7644b6d Last test of basis 100957 2016-09-14 16:12:51 Z5 days Testing same since 101016 2016-09-19 16:14:13 Z0 days2 attempts People who touched revisions under test: Andrew Cooper Marek Marczykowski-Górecki jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64
Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation
On Tue, Sep 20, 2016 at 9:39 AM, Jan Beulich wrote:
On 20.09.16 at 17:14, wrote:
>> On Tue, Sep 20, 2016 at 9:12 AM, Jan Beulich wrote:
>> On 20.09.16 at 16:56, wrote:
On Tue, Sep 20, 2016 at 1:26 AM, Jan Beulich wrote:
On 19.09.16 at 20:27, wrote:
>> On Mon, Sep 19, 2016 at 2:19 AM, Jan Beulich wrote:
>> On 15.09.16 at 18:51, wrote:
@@ -1793,7 +1793,17 @@ static int _hvm_emulate_one(struct
hvm_emulate_ctxt
>> *hvmemul_ctxt,
pfec |= PFEC_user_mode;
hvmemul_ctxt->insn_buf_eip = regs->eip;
-if ( !vio->mmio_insn_bytes )
+
+if ( unlikely(hvmemul_ctxt->set_context_insn) &&
curr->arch.vm_event )
+{
+BUILD_BUG_ON(sizeof(hvmemul_ctxt->insn_buf_bytes) ==
+ sizeof(curr->arch.vm_event->emul.insn));
>>>
>>> This should quite clearly be !=, and I think it builds only because you
>>> use the wrong operand in the first sizeof().
>>>
+hvmemul_ctxt->insn_buf_bytes =
sizeof(curr->arch.vm_event->emul.insn);
+memcpy(hvmemul_ctxt->insn_buf,
&curr->arch.vm_event->emul.insn,
+ hvmemul_ctxt->insn_buf_bytes);
>>>
>>> This memcpy()s between dissimilar types. Please omit the & and
>>> properly add .data on the second argument (and this .data
>>> addition should then also be mirrored in the BUILD_BUG_ON()).
>>>
+}
+else if ( !vio->mmio_insn_bytes )
>>>
>>> And then - I'm sorry for not having thought of this before - I think
>>> this would better not live here, or have an effect more explicitly
>>> only when coming here through hvm_emulate_one_vm_event().
>>> Since the former seems impractical, I think giving _hvm_emulate_one()
>>> one or two extra parameters would be the most straightforward
>>> approach.
>>
>> So this is the spot where the mmio insn buffer is getting copied as
>> well instead of fetching the instructions from the guest memory. So
>> having the vm_event buffer getting copied here too makes the most
>> sense. Having the vm_event insn buffer getting copied in somewhere
>> else, while the mmio insn buffer getting copied here, IMHO just
>> fragments the flow even more making it harder to see what is actually
>> happening.
>
> And I didn't unconditionally ask to move the copying elsewhere.
> The alternative - passing the override in as function argument(s),
> which would then be NULL/zero for all cases except the VM event
> one, would be as suitable. It is in particular ...
>
>> How about adjusting the if-else here to be:
>>
>> if ( !vio->mmio_insn_bytes && !hvmemul_ctxt->set_context_insn )
>> ...
>> else if ( vio->mmio_insn_bytes )
>> ...
>> else if ( unlikely(hvmemul_ctxt->set_context_insn) &&
>> curr->arch.vm_event )
>
> ... this curr->arch.vm_event reference which I'd like to see gone
> from this specific code path. The ordering in your original patch,
> otoh, would then be fine (check for the override first with unlikely(),
> else do what is being done today). Such a code structure would
> then also ease a possible second way of overriding the insn by
> some other party, without having to touch the code here again.
So that check is one that Razvan asked to be added. I think it is
necessary too as there seems to be a race-condition if vm_event gets
shutdown after the response flag is set but before this emulation path
takes place. Effectively set_context_insn may be set but the
arch.vm_event already gotten freed. Razvan, is that correct?
>>>
>>> Well, in case you misunderstood: I didn't ask for the check to be
>>> _removed_, but for it to be _moved elsewhere_.
>>>
>>
>> So as Razvan pointed out, there is a check already in hvm_do_resume
>> for exactly the same effect, so then what you are asking for is
>> already done.
>
> Partly - I really meant all curr->arch.vm_event uses to go away from
> that path. The other part (passing in the override buffer instead of
> special casing vm-event handling here) still would need to be done.
>
I don't really follow what exactly you are looking for. You want the
buffer to be sent in as an input? We can do that but I mean the mmio
case doesn't do that either.. And what do you mean not "special casing
vm_event handling"? We need to handle it in an if-statement because by
default the buffer is fetched from memory. We don't want to do that,
just as the mmio case doesn't want that either. So I think if we want
to be consistent we do what the mmio case is doing, fetching the
buffer from curr->arch.hvm_vcpu.hvm_io, only we fetch it from
curr->arch.vm_event.
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists
[Xen-devel] [libvirt test] 101029: regressions - trouble: blocked/broken/pass
flight 101029 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/101029/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 4 host-build-prep fail REGR. vs. 100999 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass version targeted for testing: libvirt 4e2d642afb454738b2e06caffeb86d20b6f33a15 baseline version: libvirt 706b5b627719e95a33606c463bc83c841c7b5b0e Last test of basis 100999 2016-09-18 04:20:39 Z2 days Testing same since 101029 2016-09-20 04:23:33 Z0 days1 attempts People who touched revisions under test: Chen Hanxiao Daniel P. Berrange Eric Blake Laine Stump Martin Kletzander Michal Privoznik jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf broken build-i386 pass build-amd64-libvirt pass build-armhf-libvirt blocked build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm blocked test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-armhf-armhf-libvirt-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit 4e2d642afb454738b2e06caffeb86d20b6f33a15 Author: Laine Stump Date: Mon Sep 19 13:44:21 2016 -0400 tests: fix use of fixedcontent variable Commit 8563560026d192c2cf047b550ffd468692245ed6 switched from hardcoded use of strcontent to hardcoded use of fixedcontent (fixedcontent is *sometimes* a copy of strcontent with a \n appended). This was a problem because sometimes fixedcontent is *not* a copy of strcontent, but is instead NULL, leading to the regenerated test case output being a 0 length file. This patch creates a new const char *cmpcontent initialized to strcontent, but changed to fixedcontent if/when fixedcontent is created, then always uses cmpcontent instead of (str|fixed)conten
Re: [Xen-devel] [PATCH v4 2/5] x86/time: implement tsc as clocksource
On 09/20/2016 02:55 PM, Jan Beulich wrote:
On 20.09.16 at 12:15, wrote:
>> On 09/20/2016 08:13 AM, Jan Beulich wrote:
>> On 19.09.16 at 19:54, wrote:
On 09/19/2016 05:25 PM, Jan Beulich wrote:
On 19.09.16 at 18:11, wrote:
>> On 09/19/2016 11:13 AM, Jan Beulich wrote:
>> On 14.09.16 at 19:37, wrote:
Since b64438c7c ("x86/time: use correct (local) time stamp in
constant-TSC calibration fast path") updates to cpu time use local
stamps, which means platform timer is only used to seed the initial
cpu time. With clocksource=tsc there is no need to be in sync with
another clocksource, so we reseed the local/master stamps to be values
of TSC and update the platform time stamps accordingly. Time
calibration is set to 1sec after we switch to TSC, thus these stamps
are reseeded to also ensure monotonic returning values right after the
point we switch to TSC. This is also to avoid the possibility of
having inconsistent readings in this short period (i.e. until
calibration fires).
>>>
>>> And within this one second, which may cover some of Dom0's
>>> booting up, it is okay to have inconsistencies?
>> It's not okay which is why I am removing this possibility when switching
>> to TSC.
>> The inconsistencies in those readings (if I wasn't adjusting) would be
>> because
>> we would be using (in that 1-sec) those cpu time tuples calculated by the
>> previous calibration or platform time initialization (while still was
>> HPET,
>> ACPI, etc as clocksource). Would you prefer me removing the "avoid" and
>> instead
>> change it to "remove the possibility" in this last sentence?
>
> Let's not do the 2nd step before the 1st, which is the question of
> what happens prior to and what actually changes at this first
> calibration (after 1 sec).
The first calibration won't change much - this 1-sec was meant when having
nop_rendezvous which is the first time platform timer would be used to set
local
cpu_time (will adjust the mention above as it's misleading for the reader
as it
doesn't refer to this patch).
>>>
>>> So what makes it that it actually _is_ nop_rendezvous after that one
>>> second? (And yes, part of this may indeed be just bad placement of
>>> the description, as iirc nop_rendezvous gets introduced only in a later
>>> patch.)
>> Because with nop_rendezvous we will be using the platform timer to get a
>> monotonic time tuple and *set* cpu_time as opposed to just adding up plain
>> TSC
>> delta as it is the case prior to b64438c7c. Thus the reseeding of the cpu
>> times
>> solves both ends of the problem, with nop_rendezvous until it is first
>> calibration fixes it, and without nop_rendezvous to remove the latch
>> adjustment
>> from initial platform timer.
>
> So am I getting you right (together with the second part of your reply
> further down) that you escape answering the question raised by saying
> that it doesn't really matter which rendezvous function gets used, when
> TSC is the clock source?
Correct and in my defense I wasn't escaping the question, as despite
unfortunate mis-mention in the patch (or bad English) I think the above
explains it. During that time window, we now just need to ensure that we will
get monotonic results solely based on the individual CPU time (i.e. calls to
get_s_time or anything that uses cpu_time). Unless the calibration function is
doing something wrong/fishy, I don't see a reason for this to go wrong.
> I.e. the introduction of nop_rendezvous is
> really just to avoid unnecessary overhead?
Yes, but note that it's only the case since recent commit b64438c7c where
cpu_time stime is now incremented with TSC based deltas with a matching TSC
stamp. Before it wasn't the case. The main difference with nop_rendezvous (other
than the significant overhead) versus std_rendezvous is that we use a single
global tuple propagated to all cpus, whereas with std_rendezvous each tuple is
different and will vary according to when it rendezvous with cpu 0.
> In which case it should
> probably be a separate patch, saying so in its description.
OK, will move that out of Patch 4 into its own while keeping the same logic.
Joao
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-4.5-testing bisection] complete build-amd64
branch xen-4.5-testing
xenbranch xen-4.5-testing
job build-amd64
testid xen-build
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 22857ab3492c35aac27691ae7184dcc935c5fb2a
Bug not present: c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/101048/
commit 22857ab3492c35aac27691ae7184dcc935c5fb2a
Author: Jan Beulich
Date: Mon Sep 19 17:50:59 2016 +0200
update Xen version to 4.5.4
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.5-testing/build-amd64.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.
Running cs-bisection-step
--graph-out=/home/logs/results/bisect/xen-4.5-testing/build-amd64.xen-build
--summary-out=tmp/101048.bisection-summary --basis-template=100909
--blessings=real,real-bisect xen-4.5-testing build-amd64 xen-build
Searching for failure / basis pass:
101024 fail [host=fiano1] / 100909 [host=godello0] 100897 [host=godello0]
100828 [host=huxelrebe0] 100814 ok.
Failure / basis pass flights: 101024 / 100814
(tree with no url: ovmf)
(tree with no url: seabios)
(tree in basispass but not in latest: qemu)
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 835c204f1196ab8f5213a9dc5299ed76e748cdca
22857ab3492c35aac27691ae7184dcc935c5fb2a
Basis pass 835c204f1196ab8f5213a9dc5299ed76e748cdca
433ebca120e8750eb8085745ccac703e47358e6f
Generating revisions with ./adhoc-revtuple-generator
git://xenbits.xen.org/qemu-xen.git#835c204f1196ab8f5213a9dc5299ed76e748cdca-835c204f1196ab8f5213a9dc5299ed76e748cdca
git://xenbits.xen.org/xen.git#433ebca120e8750eb8085745ccac703e47358e6f-22857ab3492c35aac27691ae7184dcc935c5fb2a
Loaded 1001 nodes in revision graph
Searching for test results:
100849 [host=godello0]
100814 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca
433ebca120e8750eb8085745ccac703e47358e6f
100828 [host=huxelrebe0]
100897 [host=godello0]
100930 [host=huxelrebe0]
100934 [host=huxelrebe1]
100909 [host=godello0]
101015 fail 835c204f1196ab8f5213a9dc5299ed76e748cdca
22857ab3492c35aac27691ae7184dcc935c5fb2a
101046 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca
c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
101048 fail 835c204f1196ab8f5213a9dc5299ed76e748cdca
22857ab3492c35aac27691ae7184dcc935c5fb2a
101023 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca
433ebca120e8750eb8085745ccac703e47358e6f
101030 fail 835c204f1196ab8f5213a9dc5299ed76e748cdca
22857ab3492c35aac27691ae7184dcc935c5fb2a
101033 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca
95559492c958e45fa7c01b1b3e0fb704e5b8b9eb
101034 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca
9edce7c42e6c2e8dd19788cab688cb46f779a9ec
101035 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca
c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
101037 fail 835c204f1196ab8f5213a9dc5299ed76e748cdca
22857ab3492c35aac27691ae7184dcc935c5fb2a
101039 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca
c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
101024 fail 835c204f1196ab8f5213a9dc5299ed76e748cdca
22857ab3492c35aac27691ae7184dcc935c5fb2a
101044 fail 835c204f1196ab8f5213a9dc5299ed76e748cdca
22857ab3492c35aac27691ae7184dcc935c5fb2a
Searching for interesting versions
Result found: flight 100814 (pass), for basis pass
Result found: flight 101015 (fail), for basis failure
Repro found: flight 101023 (pass), for basis pass
Repro found: flight 101024 (fail), for basis failure
0 revisions at 835c204f1196ab8f5213a9dc5299ed76e748cdca
c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
No revisions left to test, checking graph state.
Result found: flight 101035 (pass), for last pass
Result found: flight 101037 (fail), for first failure
Repro found: flight 101039 (pass), for last pass
Repro found: flight 101044 (fail), for first failure
Repro found: flight 101046 (pass), for last pass
Repro found: flight 101048 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 22857ab3492c35aac27691ae7184dcc935c5fb2a
Bug not present: c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/101048/
commit 22857ab3492c35aac27691ae7184dcc935c5fb2a
Author: Jan Beulich
Date: Mon Sep 19 17:50:59 2016 +0200
update Xen version to 4.5.4
Revision graph left in
/home/logs/results/bisect/xen-4.5-testing/build-amd64.xen-build.{dot,ps,png,html,svg}.
101048: tolerable ALL FAIL
flight 101048 xen-4.5-testing real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/101048/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
build-amd64
Re: [Xen-devel] [PATCH v2 3/3] Significant changes to decision making; some new roles and minor changes
Lars Kurth writes ("[PATCH v2 3/3] Significant changes to decision making; some
new roles and minor changes"):
> [proposal]
Thanks. I've reviewed this and it looks generally good but I have
some specific comments.
Throughout you use "gage" where I think you should use "gauge".
(AFAICT from Wiktionary this is not a US/UK spelling thing.)
> +Voting is conducted in line with the following rules:
> +
> +- Project leadership team members vote for (**+1**) or against (**-1**) a
> +resolution. There is no differentiation between **+1**/ **+2** and
> +**-1**/**-2**: in other words a **+2** is counted as a vote for, a **-2** as
> a
> +vote against the resolution. The number of votes for and against a
> resolution
> +is called **active vote**. **0** votes **are not counted** as an active vote.
> +- A **quorum of more than 50% of active votes** is required for a
> resolution
> +to pass. In other words, if the leadership team has 7 members, at least 4
> +active votes are required for a resolution to pass.
> +- The resolution passes, if a 2/3 majority of active votes is in favour of
> +it.
Quorums like this should count only positive votes. Otherwise someone
who opposes a proposal has to guess whether it is more likely to fail
quorum, or to fail the 2/3 majority. If it is likely to fail quorum,
they should refrain from voting.
For example with a team of 6, with two people having alread voted yes,
and the remaining three having expressly declined to vote because they
don't have an opinion, a leadership team member who votes "no" would
move the outcome from "quorum not met since only 2 out of 6 active
voters - fail" to "quorum met with 3 active voters, 2 votes in favour,
one against, 2/3 majority met - pass".
I suggest changing the quorum threshold to count only explicit
abstentions and votes in favour; either 1/3 or 50% would do.
> -### Conflict Resolution
> +Let me express this as an algorithm.
>
> -
> -
> -ISSUES TO BE ADDRESSED LATER:
> -- Generalise refereeing in terms of Project Leadership instead of
> specific roles
> -- Also some examples for sPecific situations that have happened in the
> past may be
> - useful
> -
> -
> + treshhold=2/3;
threshold
> + active='number of active members'; (7 for the Hypervisor project; IanC
> is inactive)
^
at the time of writing,
2016-09-20
> - Refereeing
> +One open question is what to do with 0-votes. We could introduce a rule
> discounting
> +0 votes (let's call it 0-rule). If someone votes 0, we assume they
> really don't care
> +about the outcome and are considered inactive for the purpose of the
> vote.
With my proposal you can delete this because 0-votes do not affect
quorum.
> +The other question is whether to treat -2-votes different than -1-votes.
> We could
> +say there should not be more than 20% -2-votes. That would mean that
No. Formal decisonmaking of this sort should not count some votes
double.
> +The entire last resource section goes, because it is essentially not
> needed any more,
resort
> + Committer, Security Team Member and other Project Leadership Elections
...
> - Nomination: Community members should nominate candidates by posting a
> proposal to *appointments at xenproject dot org* explaining the candidate's
> @@ -299,74 +606,123 @@ review all proposals, check whether the nominee would
> be willing to accept the
> nomination and publish suitable nominations on the project's public mailing
> list for wider community input.
> - Election: A committer will be elected using the decision making process
> -outlined earlier. Voting will be done by committers for that project
> privately
> -using a voting form that is created by the community manager. Should there
> be a
> -negative vote the project lead and community manager will try and resolve
> the
> -situation and reach consensus. Results will be published on the public
> mailing
> -list.
> +outlined earlier. In other words, the decision is delegated to the [project
> +leadership team](#leadership).
This misses out appointments to the security team. I suggest that
they should usually be made by the team itself according to lazy
consensus.
> +
> -
>
> + **Proposal** **Who reviews?** **Who votes?**
> + - -
> -
> + Creating, graduating, Members of developer mailing Leadership
> teams of
> +
[Xen-devel] [xen-unstable-smoke test] 101047: tolerable all pass - PUSHED
flight 101047 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101047/
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 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen 8fec44f23cf59d9be02df055b40e9f9536a0d570
baseline version:
xen f1446de4ba5218a58fa2486ebe090495e0fb05c4
Last test of basis 101018 2016-09-19 18:02:42 Z0 days
Testing same since 101047 2016-09-20 14:02:30 Z0 days1 attempts
People who touched revisions under test:
Ian Jackson
Jan Beulich
Wei Liu
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable-smoke
+ revision=8fec44f23cf59d9be02df055b40e9f9536a0d570
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
8fec44f23cf59d9be02df055b40e9f9536a0d570
+ branch=xen-unstable-smoke
+ revision=8fec44f23cf59d9be02df055b40e9f9536a0d570
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x8fec44f23cf59d9be02df055b40e9f9536a0d570 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/
Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC
On Tue, 2016-09-20 at 17:34 +0200, Julien Grall wrote: > On 20/09/2016 12:27, George Dunlap wrote: > > I think we definitely need to have Xen have some kind of idea the > > order between processors, so that the user doesn't need to figure > > out > > which class / pool is big and which pool is LITTLE. Whether this > > sort > > of enumeration is the best way to do that I'll let Julien and > > Stefano > > give their opinion. > > I don't think an hardcoded list of processor in Xen is the right > solution. There are many existing processors and combinations for > big.LITTLE so it will nearly be impossible to keep updated. > As far as either the scheduler or cpupools go, what's necessary would be: - in Xen, a function (or an array acting as a map, or whatever) to call to know whether pcpu X is big or LITTLE; - at toolstack level, an hypercal (or a field, bit, whatever in a struct already returned by an existing hypercall) to know the same thing, i.e., whether c pcpu is big or LITTLE. Once we have this, we can do everything. We will probably want to abstract things a bit, and make them as generic as practical, so that the same interface can be used not only for ARM big.LITTLE, but for whatever future heterogeneous cpu arch we'll support... but really, the actual information that we need is "just" that. I've absolutely no idea how such info could be achieved, and I have no ARM big.LITTLE hardware to test on. > I would expect the firmware table (device tree, ACPI) to provide > relevant data for each processor and differentiate big from LITTLE > core. > Note that I haven't looked at it for now. A good place to start is > looking at how Linux does. > Makes sense. Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Question about VPID during MOV-TO-CR3
Hi all, I'm trying to figure out the design decision regarding the handling of guest MOV-TO-CR3 operations and TLB flushes. AFAICT since support for VPID has been added to Xen, every guest MOV-TO-CR3 flushes the TLB (vmx_cr_access -> hvm_mov_to_cr -> hvm_set_cr3 -> paging_update_cr3 -> hap_update_cr3 -> vmx_update_guest_cr -> hvm_asid_flush_vcpu). From a TLB utilization point-of-view this seems to be rather wasteful. Furthermore, it even breaks the guests' ability to take advantage of PCID, as the TLB just guts flushed when a new process is scheduled. Does anyone have an insight into what was the rationale behind this? Thanks, Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 01/15] x86: properly calculate ELF end of image address
On Mon, Sep 19, 2016 at 08:52:02AM -0600, Jan Beulich wrote: > >>> On 19.09.16 at 15:56, wrote: > > On Mon, Sep 19, 2016 at 05:14:07AM -0600, Jan Beulich wrote: [...] > >> So before taking this patch I'd really like to see proof that what gets > >> done currently does actually go wrong in at least one case. So far I > > > > During initial work on this patch series I discovered that p_memsz in xen > > ELF file is set to unreasonably huge value, IIRC, ~1 GiB. That is why at > > first I enforced 16 MiB here (just temporary workaround) and later proposed > > this patch. Sadly, right now I am not able to find commit which introduced > > this issue. However, it seems that it was "fixed" later by another commit. > > > > Anyway, I am not sure why are you against, IMO, more reliable solution. > > This way we would avoid in the future similar issues which I described > > above. > > I'm not against anything if it gets properly explained. Here, > however, you present some vague statements which even you > can't verify right now as it looks. OK, I did some more tests and found out that after patch "efi: build xen.gz with EFI code" we have following xen ELF file: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x80 0x0010 0x0010 0x20c120 0x3ff0 RWE 0x40 ^^ because "nm -nr xen/xen-syms" emits: 82d0c000 A ALT_START 82d08034d000 A __2M_rwdata_end 82d08034cc00 A _end 82d08034cc00 B __per_cpu_data_end 82d08034cc00 B __bss_end [...] ALT_START lives in xen/arch/x86/efi/relocs-dummy.S. relocs-dummy.S provides __base_relocs_start and __base_relocs_end symbols which are referenced in xen/arch/x86/efi/efi-boot.h:efi_arch_relocate_image(). Of course one can argue that maybe we should do some changes in efi_arch_relocate_image() and/or xen/arch/x86/efi/relocs-dummy.S. This is true. However, this is separate issue and we should consider it as such. "efi: build xen.gz with EFI code" patch clearly shows that current method used to calculate mkelf32 argument is based on bogus assumptions and very fragile. So, IMO, it should be changed to something which is more reliable. And my proposal looks quite good. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Fixes for low memory allocation machinery in early boot code
On Tue, Sep 20, 2016 at 07:23:06AM -0600, Jan Beulich wrote: > >>> On 20.09.16 at 14:11, wrote: > > On Fri, Sep 16, 2016 at 06:15:10AM -0600, Jan Beulich wrote: > >> >>> On 14.09.16 at 10:23, wrote: > >> > Additionally, my investigation has shown that there are no bound checks > >> > in > >> > low memory allocation machinery for trampoline (by the way, in BIOS path > >> > we > >> > allocate 64 KiB for trampoline but in EFI code we properly calculate its > >> > size; > >> > so, I think we should do the same calculation in BIOS path), stack and > >> > boot data > >> > taken from multiboot protocol. Hence, relevant fixes should be added > >> > here too. > >> > >> Would be nice, yes, but we need to weigh the need to presumably do > >> at least some of this in assembly code (for now at least) against the > >> potential gain. > >> > >> > Moreover I think that at least allocation machinery with additional > >> > checks > >> > described in last paragraph can be used on EFI platforms when Xen is > >> > booted > >> > via multiboot2 protocol. However, then high limit should be defined as 1 > >> > MiB. > >> > Though I think that low limit, 256 KiB, should stay as is. > >> > >> Why 1Mb? The 640k limit derives from hardware aspects, but doesn't > >> depend on the software environment. > > > > I do not expect that anything which is not memory will reside between 640 > > KiB > > and 1 MiB on EFI platforms. So, if firmware says that it is usable why we > > cannot > > use it? And I have a feeling that this idea lead to currently existing > > checks > > around trampoline allocation code for EFI. Though, as I saw EFI platforms > > usually does not expose region 640 KiB and 1 MiB as usable. However, this > > does not mean that they cannot in the future. > > Hmm, when the region (or part of it) is reported as available, then I > guess we could use it. But as to there being RAM - I doubt it, since > for the next little while, EFI or not, we're talking about PC compatible > systems, which don't normally have RAM in that range. If we drop BIOS and move to EFI then compatibility with PC drops to tiny fraction of original platform. So, in this context lack of VGA or anything like that above 640 KiB is not an issue IMO and memory there would not be very big surprise for me. However, if you care I would ask why do you use 1 MiB limit instead of 640 KiB in xen/arch/x86/efi/efi-boot.h? I do not say this is huge mistake but I am curious why not 640 KiB? I suppose that there was a reason for it but I cannot find anything about that in comments or commit messages. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 08/15] x86/efi: create new early memory allocator
On Tue, Sep 20, 2016 at 07:46:56AM -0600, Jan Beulich wrote:
> >>> On 20.09.16 at 12:52, wrote:
> > On Tue, Sep 20, 2016 at 03:57:19AM -0600, Jan Beulich wrote:
> >> >>> On 20.09.16 at 11:45, wrote:
> >> > On Mon, Sep 19, 2016 at 09:17:50AM -0600, Jan Beulich wrote:
> >> >> >>> On 19.09.16 at 17:04, wrote:
> >> >> > On Mon, Sep 19, 2016 at 06:12:35AM -0600, Jan Beulich wrote:
> >> >> >> >>> On 12.09.16 at 22:18, wrote:
> >> >> >> > --- a/xen/arch/x86/setup.c
> >> >> >> > +++ b/xen/arch/x86/setup.c
> >> >> >> > @@ -520,6 +520,8 @@ static void noinline init_done(void)
> >> >> >> >
> >> >> >> > system_state = SYS_STATE_active;
> >> >> >> >
> >> >> >> > +free_ebmalloc_unused_mem();
> >> >> >>
> >> >> >> Now that the allocator properly lives in common code, this appears
> >> >> >> to lack an ARM side counterpart.
> >> >> >
> >> >> > Why? It is called only from xen/arch/x86/setup.c:__start_xen() and all
> >> >> > ebmalloc stuff is in #ifndef CONFIG_ARM. So,
> >> >> > free_ebmalloc_unused_mem()
> >> >> > will be needed only if we add ARM support here.
> >> >>
> >> >> Well, it being inside that conditional is part of the problem - there's
> >> >> no apparent point for all of it to be.
> >> >
> >> > I can agree that this is potentially generic stuff (well, I understand
> >> > that
> >> > it is our final goal but unreachable yet due to various things). However,
> >> > right know it is only used on x86. So, I am not sure what is the problem
> >> > with #ifndef CONFIG_ARM right now...
> >>
> >> It is a fact that these should actually not be there, so we ought to
> >> at least limit them to the smallest possible count and scopes.
> >>
> >> >> Arguably the one static function may better be, as other workarounds
> >> >> to avoid the "unused" compiler warning wouldn't be any better.
> >> >
> >> > Do you mean static function with empty body for ARM? It is not needed
> >> > right now because it is never called on ARM. Am I missing something?
> >>
> >> You misunderstood - I said that for this one (unused) static
> >> function such an #ifdef is probably okay, as the presumably
> >> smallest possible workaround.
> >
> > Do you suggest that I should move out of #ifndef CONFIG_ARM all ebmalloc
> > stuff
> > except free_ebmalloc_unused_mem(). Even if it is not used on ARM right now?
>
> That's not the static function, is it? The function you name should
> actually be called on ARM too (as I did point out elsewhere already),
> just to not leave a trap open for someone to fall into when (s)he
> adds a first use of the allocator on ARM.
Well, I think that sane person doing that would analyze how ebmalloc works
on x86 and then move (align to ARM needs if required) all its machinery
(including free_ebmalloc_unused_mem()) to run on ARM. At least I would do
that. This way he/she would avoid issues mentioned by you. However, if you
still prefer your way I can do that. Though I am not sure about the rest of
ebmalloc stuff. Should I move it out of #ifndef CONFIG_ARM? Looking at your
earlier replies I see that yes. Am I correct?
> >> >> >> > +static unsigned long __initdata ebmalloc_allocated;
> >> >> >> > +
> >> >> >> > +/* EFI boot allocator. */
> >> >> >> > +static void __init *ebmalloc(size_t size)
> >> >> >> > +{
> >> >> >> > +void *ptr = ebmalloc_mem + ebmalloc_allocated;
> >> >> >> > +
> >> >> >> > +ebmalloc_allocated += (size + sizeof(void *) - 1) &
> >> >> >> > ~((typeof(size))sizeof(void *) - 1);
> >> >> >>
> >> >> >> What's the point of this ugly cast?
> >> >> >
> >> >> > In general ALIGN_UP() would be nice here. However, there is no such
> >> >> > thing
> >> >> > in Xen headers (or I cannot find it). Should I add one? As separate
> >> >> > patch?
> >> >>
> >> >> I understand what you want the expression for, but you didn't
> >> >> answer my question. Or do you not realize that all this cast is
> >> >> about is a strange way of converting an expression of type
> >> >> size_t to type size_t?
> >> >
> >> > Does sizeof() returns size_t type? I was thinking that it returns
> >> > a number calculated during compilation, however, it does not have
> >> > specific type.
> >>
> >> Every expression needs to have a well specified type. Even
> >> plain numbers do.
> >
> > Hmmm... So, what is a type e.g. 5 without "U" and/or "L"? int?
>
> Of course. But please may I ask you to read the spec instead?
Thanks! Sure thing!
Daniel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] Significant changes to decision making; some new roles and minor changes
On 20/09/2016 18:01, "Ian Jackson" wrote:
>Lars Kurth writes ("[PATCH v2 3/3] Significant changes to decision
>making; some new roles and minor changes"):
>> [proposal]
>
>Thanks. I've reviewed this and it looks generally good but I have
>some specific comments.
>
>
>Throughout you use "gage" where I think you should use "gauge".
>(AFAICT from Wiktionary this is not a US/UK spelling thing.)
Will fix.
>> +Voting is conducted in line with the following rules:
>> +
>> +- Project leadership team members vote for (**+1**) or against
>>(**-1**) a
>> +resolution. There is no differentiation between **+1**/ **+2** and
>> +**-1**/**-2**: in other words a **+2** is counted as a vote for, a
>>**-2** as a
>> +vote against the resolution. The number of votes for and against a
>>resolution
>> +is called **active vote**. **0** votes **are not counted** as an
>>active vote.
>> +- A **quorum of more than 50% of active votes** is required for a
>>resolution
>> +to pass. In other words, if the leadership team has 7 members, at
>>least 4
>> +active votes are required for a resolution to pass.
>> +- The resolution passes, if a 2/3 majority of active votes is in
>>favour of
>> +it.
>
>Quorums like this should count only positive votes. Otherwise someone
>who opposes a proposal has to guess whether it is more likely to fail
>quorum, or to fail the 2/3 majority. If it is likely to fail quorum,
>they should refrain from voting.
I think probably the term quorum is leading to some confusion here and
should probably be changed. Basically what
+- A **quorum of more than 50% of active votes** is required for a
resolution
+to pass. In other words, if the leadership team has 7 members, at least 4
+active votes are required for a resolution to pass.
is trying to encode is a turnout threshold of >50% (discounting spoilt
ballot papers: in other words a **0** votes would be the equivalent of a
spoilt ballot paper). My thinking was that
A) The rules would encourage team members to vote for or against a
proposal, rather than abstain
B) The minimum threshold is there to ensure that we don't have to manage
disappearing leadership team members tightly and that decisions have
enough legitimacy
C) The 2/3 majority would only apply to the people that have voted for or
against a proposal
>For example with a team of 6, with two people having alread voted yes,
>and the remaining three having expressly declined to vote because they
>don't have an opinion, a leadership team member who votes "no" would
>move the outcome from "quorum not met since only 2 out of 6 active
>voters - fail" to "quorum met with 3 active voters, 2 votes in favour,
>one against, 2/3 majority met - pass".
This is wrong. With a team of 6, at least 4 people would need to vote
"yes" or "no" to pass the 50% threshold. If more than "2" decline to vote,
the threshold wont be achieved. Amongst the 4 votes, 3 would need to be in
favour.
But you are right, this does open the door to tactical voting in some
boundary cases. So if there were 2 active "0" votes and 3 "+1" votes, the
last voter could shoot down the proposal by voting "0". If the vote had
been secret, that person would probably vote "-1" and the proposal would
pass. The same applies, if we were close to the voting deadline and 3
people had voted "+1" and 2 had not.
I am not quite sure I understand what you mean by "otherwise someone who
opposes a proposal has to guess whether it is more likely to fail quorum,
or to fail the 2/3 majority", but I guess it is what I outlined above. I
suppose the whole issue would go away, if there was a secret vote. But
introducing this, would be a bit heavyweight.
>I suggest changing the quorum threshold to count only explicit
>abstentions and votes in favour; either 1/3 or 50% would do.
I am not suggesting this is a bad idea, but I don't think I fully
understand what you mean and how your proposal avoids the issue above.
>> -### Conflict Resolution
>> +Let me express this as an algorithm.
>>
>> -
>>-
>>
>> -ISSUES TO BE ADDRESSED LATER:
>> -- Generalise refereeing in terms of Project Leadership instead of
>>specific roles
>> -- Also some examples for sPecific situations that have happened in
>>the past may be
>> - useful
>> -
>>-
>>
>> + treshhold=2/3;
>
> threshold
>
>> + active='number of active members'; (7 for the Hypervisor
>>project; IanC is inactive)
>
> ^
> at the time of
>writing, 2016-09-20
>
>> - Refereeing
>> +One open question is what to do with 0-votes. We could introduce a
>>rule discounting
>> +0 votes (let's call it 0-rule). If someone votes 0, we assume they
>>really don't care
>> +about the
Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC
On Tue, 20 Sep 2016, Julien Grall wrote:
> Hi,
>
> On 20/09/2016 12:27, George Dunlap wrote:
> > On Tue, Sep 20, 2016 at 11:03 AM, Peng Fan wrote:
> > > On Tue, Sep 20, 2016 at 02:54:06AM +0200, Dario Faggioli wrote:
> > > > On Mon, 2016-09-19 at 17:01 -0700, Stefano Stabellini wrote:
> > > > > On Tue, 20 Sep 2016, Dario Faggioli wrote:
> > > I'd like to add a computing capability in xen/arm, like this:
> > >
> > > struct compute_capatiliby
> > > {
> > >char *core_name;
> > >uint32_t rank;
> > >uint32_t cpu_partnum;
> > > };
> > >
> > > struct compute_capatiliby cc=
> > > {
> > > {"A72", 4, 0xd08},
> > > {"A57", 3, 0},
> > > {"A53", 2, 0xd03},
> > > {"A35", 1, ...},
> > > }
> > >
> > > Then when identify cpu, we decide which cpu is big and which cpu is little
> > > according to the computing rank.
> > >
> > > Any comments?
> >
> > I think we definitely need to have Xen have some kind of idea the
> > order between processors, so that the user doesn't need to figure out
> > which class / pool is big and which pool is LITTLE. Whether this sort
> > of enumeration is the best way to do that I'll let Julien and Stefano
> > give their opinion.
>
> I don't think an hardcoded list of processor in Xen is the right solution.
> There are many existing processors and combinations for big.LITTLE so it will
> nearly be impossible to keep updated.
>
> I would expect the firmware table (device tree, ACPI) to provide relevant data
> for each processor and differentiate big from LITTLE core.
> Note that I haven't looked at it for now. A good place to start is looking at
> how Linux does.
That's right, see Documentation/devicetree/bindings/arm/cpus.txt. It is
trivial to identify the two different CPU classes and which cores belong
to which class. It is harder to figure out which one is supposed to be
big and which one LITTLE. Regardless, we could default to using the
first cluster (usually big), which is also the cluster of the boot cpu,
and utilize the second cluster only when the user demands it.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 101032: trouble: broken/fail/pass
flight 101032 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/101032/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-vhd 3 host-install(3)broken REGR. vs. 101017 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101017 test-amd64-amd64-xl-rtds 9 debian-install fail like 101017 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101017 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass version targeted for testing: qemuu33e1666b4289313306371fee0740f5c85517e406 baseline version: qemuu3d47a1390bd80b7b974185827a340012d21ad1e3 Last test of basis 101017 2016-09-19 17:22:00 Z1 days Testing same since 101032 2016-09-20 05:57:15 Z0 days1 attempts People who touched revisions under test: Marc-André Lureau Markus Armbruster Peter Maydell jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC
Hi Stefano,
On 20/09/2016 20:09, Stefano Stabellini wrote:
On Tue, 20 Sep 2016, Julien Grall wrote:
Hi,
On 20/09/2016 12:27, George Dunlap wrote:
On Tue, Sep 20, 2016 at 11:03 AM, Peng Fan wrote:
On Tue, Sep 20, 2016 at 02:54:06AM +0200, Dario Faggioli wrote:
On Mon, 2016-09-19 at 17:01 -0700, Stefano Stabellini wrote:
On Tue, 20 Sep 2016, Dario Faggioli wrote:
I'd like to add a computing capability in xen/arm, like this:
struct compute_capatiliby
{
char *core_name;
uint32_t rank;
uint32_t cpu_partnum;
};
struct compute_capatiliby cc=
{
{"A72", 4, 0xd08},
{"A57", 3, 0},
{"A53", 2, 0xd03},
{"A35", 1, ...},
}
Then when identify cpu, we decide which cpu is big and which cpu is little
according to the computing rank.
Any comments?
I think we definitely need to have Xen have some kind of idea the
order between processors, so that the user doesn't need to figure out
which class / pool is big and which pool is LITTLE. Whether this sort
of enumeration is the best way to do that I'll let Julien and Stefano
give their opinion.
I don't think an hardcoded list of processor in Xen is the right solution.
There are many existing processors and combinations for big.LITTLE so it will
nearly be impossible to keep updated.
I would expect the firmware table (device tree, ACPI) to provide relevant data
for each processor and differentiate big from LITTLE core.
Note that I haven't looked at it for now. A good place to start is looking at
how Linux does.
That's right, see Documentation/devicetree/bindings/arm/cpus.txt. It is
trivial to identify the two different CPU classes and which cores belong
to which class.t, as
The class of the CPU can be found from the MIDR, there is no need to use
the device tree/acpi for that. Note that I don't think there is an easy
way in ACPI (i.e not in AML) to find out the class.
It is harder to figure out which one is supposed to be
big and which one LITTLE. Regardless, we could default to using the
first cluster (usually big), which is also the cluster of the boot cpu,
and utilize the second cluster only when the user demands it.
Why do you think the boot CPU will usually be a big one? In the case of
Juno platform it is configurable, and the boot CPU is a little core on
r2 by default.
In any case, what we care about is differentiate between two set of
CPUs. I don't think Xen should care about migrating a guest vCPU between
big and LITTLE cpus. So I am not sure why we would want to know that.
The only thing we need an identifier for each set (I might be the MIDR
or the compatible in the device tree).
Note that, as Peng mentioned, Linaro is working on an energy-aware
scheduler. So there is a way (maybe not yet upstreamed) to find the CPU
topology.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 101056: tolerable all pass - PUSHED
flight 101056 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101056/
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 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen a9c9600bb5b2f79058ce24f0ef51f22c78e89ba1
baseline version:
xen 8fec44f23cf59d9be02df055b40e9f9536a0d570
Last test of basis 101047 2016-09-20 14:02:30 Z0 days
Testing same since 101056 2016-09-20 18:03:25 Z0 days1 attempts
People who touched revisions under test:
Dongli Zhang
George Dunlap
Ian Jackson
Jan Beulich
Juergen Gross
Wei Liu
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable-smoke
+ revision=a9c9600bb5b2f79058ce24f0ef51f22c78e89ba1
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
a9c9600bb5b2f79058ce24f0ef51f22c78e89ba1
+ branch=xen-unstable-smoke
+ revision=a9c9600bb5b2f79058ce24f0ef51f22c78e89ba1
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' xa9c9600bb5b2f79058ce24f0ef51f22c78e89ba1 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/lin
Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC
On Tue, 20 Sep 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 20/09/2016 20:09, Stefano Stabellini wrote:
> > On Tue, 20 Sep 2016, Julien Grall wrote:
> > > Hi,
> > >
> > > On 20/09/2016 12:27, George Dunlap wrote:
> > > > On Tue, Sep 20, 2016 at 11:03 AM, Peng Fan
> > > > wrote:
> > > > > On Tue, Sep 20, 2016 at 02:54:06AM +0200, Dario Faggioli wrote:
> > > > > > On Mon, 2016-09-19 at 17:01 -0700, Stefano Stabellini wrote:
> > > > > > > On Tue, 20 Sep 2016, Dario Faggioli wrote:
> > > > > I'd like to add a computing capability in xen/arm, like this:
> > > > >
> > > > > struct compute_capatiliby
> > > > > {
> > > > >char *core_name;
> > > > >uint32_t rank;
> > > > >uint32_t cpu_partnum;
> > > > > };
> > > > >
> > > > > struct compute_capatiliby cc=
> > > > > {
> > > > > {"A72", 4, 0xd08},
> > > > > {"A57", 3, 0},
> > > > > {"A53", 2, 0xd03},
> > > > > {"A35", 1, ...},
> > > > > }
> > > > >
> > > > > Then when identify cpu, we decide which cpu is big and which cpu is
> > > > > little
> > > > > according to the computing rank.
> > > > >
> > > > > Any comments?
> > > >
> > > > I think we definitely need to have Xen have some kind of idea the
> > > > order between processors, so that the user doesn't need to figure out
> > > > which class / pool is big and which pool is LITTLE. Whether this sort
> > > > of enumeration is the best way to do that I'll let Julien and Stefano
> > > > give their opinion.
> > >
> > > I don't think an hardcoded list of processor in Xen is the right solution.
> > > There are many existing processors and combinations for big.LITTLE so it
> > > will
> > > nearly be impossible to keep updated.
> > >
> > > I would expect the firmware table (device tree, ACPI) to provide relevant
> > > data
> > > for each processor and differentiate big from LITTLE core.
> > > Note that I haven't looked at it for now. A good place to start is looking
> > > at
> > > how Linux does.
> >
> > That's right, see Documentation/devicetree/bindings/arm/cpus.txt. It is
> > trivial to identify the two different CPU classes and which cores belong
> > to which class.t, as
>
> The class of the CPU can be found from the MIDR, there is no need to use the
> device tree/acpi for that. Note that I don't think there is an easy way in
> ACPI (i.e not in AML) to find out the class.
>
> > It is harder to figure out which one is supposed to be
> > big and which one LITTLE. Regardless, we could default to using the
> > first cluster (usually big), which is also the cluster of the boot cpu,
> > and utilize the second cluster only when the user demands it.
>
> Why do you think the boot CPU will usually be a big one? In the case of Juno
> platform it is configurable, and the boot CPU is a little core on r2 by
> default.
>
> In any case, what we care about is differentiate between two set of CPUs. I
> don't think Xen should care about migrating a guest vCPU between big and
> LITTLE cpus. So I am not sure why we would want to know that.
No, it is not about migrating (at least yet). It is about giving useful
information to the user. It would be nice if the user had to choose
between "big" and "LITTLE" rather than "class 0x1" and "class 0x100", or
even "A7" or "A15".
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [RFC PATCH] xs: use system's default stack size for xs_watch's reader thread
From: Chris Patterson
xs_watch() creates a thread to listen to xenstore events. Currently, the
thread is created with the greater of 16K or PTHREAD_MIN_SIZE.
There have been several bug reports and workarounds related to the issue
where xs_watch() fails because its attempt to create the reader thread with
pthread_create() fails. This is due to insufficient stack space size
given the requirements for thread-local storage usage in the applications
and libraries that are linked against libxenstore. [1,2,3,4].
Specifying the stack size appears to have been added to reduce memory
footprint (1d00c73b983b09fbee4d9dc0f58f6663c361c345).
This has already been bumped up once to the greater of 16k and
PTHREAD_STACK_MIN (da6a0e86d6a079102abdd0858a19f1e1fae584fc).
This patch reverts to sticking with the system's default stack size and
removes the code used to set the thread's stack size.
Of course, the alternative is to bump it to another arbitrary value, but the
requirements may change depending on the application and its libraries that
are linking against xenstore.
[1] https://lists.nongnu.org/archive/html/qemu-devel/2016-07/msg03341.html
[2] https://lists.xenproject.org/archives/html/xen-users/2016-07/msg00012.html
[3] https://lists.xenproject.org/archives/html/xen-users/2016-07/msg00085.html
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1350264
Signed-off-by: Chris Patterson
---
tools/xenstore/xs.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index d1e01ba..c62b120 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -723,11 +723,6 @@ bool xs_watch(struct xs_handle *h, const char *path, const
char *token)
struct iovec iov[2];
#ifdef USE_PTHREAD
-#define DEFAULT_THREAD_STACKSIZE (16 * 1024)
-#define READ_THREAD_STACKSIZE \
- ((DEFAULT_THREAD_STACKSIZE < PTHREAD_STACK_MIN) ? \
- PTHREAD_STACK_MIN : DEFAULT_THREAD_STACKSIZE)
-
/* We dynamically create a reader thread on demand. */
mutex_lock(&h->request_mutex);
if (!h->read_thr_exists) {
@@ -738,11 +733,6 @@ bool xs_watch(struct xs_handle *h, const char *path, const
char *token)
mutex_unlock(&h->request_mutex);
return false;
}
- if (pthread_attr_setstacksize(&attr, READ_THREAD_STACKSIZE) !=
0) {
- pthread_attr_destroy(&attr);
- mutex_unlock(&h->request_mutex);
- return false;
- }
sigfillset(&set);
pthread_sigmask(SIG_SETMASK, &set, &old_set);
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 101043: all pass - PUSHED
flight 101043 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101043/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b6e89910dd31e38944900ddc5cb4b86cf25241b4
baseline version:
ovmf 0a92ac8802704d7281ff7b9bc00ec4f893c3ece2
Last test of basis 101025 2016-09-20 01:49:01 Z0 days
Testing same since 101043 2016-09-20 11:51:49 Z0 days1 attempts
People who touched revisions under test:
Satya Yarlagadda
Star Zeng
Yonghong Zhu
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=ovmf
+ revision=b6e89910dd31e38944900ddc5cb4b86cf25241b4
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf
b6e89910dd31e38944900ddc5cb4b86cf25241b4
+ branch=ovmf
+ revision=b6e89910dd31e38944900ddc5cb4b86cf25241b4
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xb6e89910dd31e38944900ddc5cb4b86cf25241b4 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.
[Xen-devel] [xen-4.5-testing bisection] complete build-i386
branch xen-4.5-testing
xenbranch xen-4.5-testing
job build-i386
testid xen-build
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 22857ab3492c35aac27691ae7184dcc935c5fb2a
Bug not present: c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/101068/
commit 22857ab3492c35aac27691ae7184dcc935c5fb2a
Author: Jan Beulich
Date: Mon Sep 19 17:50:59 2016 +0200
update Xen version to 4.5.4
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.5-testing/build-i386.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.
Running cs-bisection-step
--graph-out=/home/logs/results/bisect/xen-4.5-testing/build-i386.xen-build
--summary-out=tmp/101068.bisection-summary --basis-template=100909
--blessings=real,real-bisect xen-4.5-testing build-i386 xen-build
Searching for failure / basis pass:
101024 fail [host=baroque1] / 100909 [host=pinot0] 100897 [host=pinot0] 100828
[host=elbling0] 100814 [host=pinot0] 100769 ok.
Failure / basis pass flights: 101024 / 100769
(tree with no url: ovmf)
(tree with no url: seabios)
(tree in basispass but not in latest: qemu)
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 835c204f1196ab8f5213a9dc5299ed76e748cdca
22857ab3492c35aac27691ae7184dcc935c5fb2a
Basis pass 835c204f1196ab8f5213a9dc5299ed76e748cdca
d50078b9f2d7df55157ca353d889b13a8f3f0bc6
Generating revisions with ./adhoc-revtuple-generator
git://xenbits.xen.org/qemu-xen.git#835c204f1196ab8f5213a9dc5299ed76e748cdca-835c204f1196ab8f5213a9dc5299ed76e748cdca
git://xenbits.xen.org/xen.git#d50078b9f2d7df55157ca353d889b13a8f3f0bc6-22857ab3492c35aac27691ae7184dcc935c5fb2a
Loaded 1001 nodes in revision graph
Searching for test results:
100769 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca
d50078b9f2d7df55157ca353d889b13a8f3f0bc6
100849 [host=baroque0]
100814 [host=pinot0]
100828 [host=elbling0]
100897 [host=pinot0]
100909 [host=pinot0]
101015 fail 835c204f1196ab8f5213a9dc5299ed76e748cdca
22857ab3492c35aac27691ae7184dcc935c5fb2a
101065 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca
c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
101066 fail 835c204f1196ab8f5213a9dc5299ed76e748cdca
22857ab3492c35aac27691ae7184dcc935c5fb2a
101067 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca
c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
101052 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca
d50078b9f2d7df55157ca353d889b13a8f3f0bc6
101068 fail 835c204f1196ab8f5213a9dc5299ed76e748cdca
22857ab3492c35aac27691ae7184dcc935c5fb2a
101054 fail 835c204f1196ab8f5213a9dc5299ed76e748cdca
22857ab3492c35aac27691ae7184dcc935c5fb2a
101055 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca
11c0462417051f56be0537c8cbf5973b2c648c2a
101024 fail 835c204f1196ab8f5213a9dc5299ed76e748cdca
22857ab3492c35aac27691ae7184dcc935c5fb2a
101057 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca
95559492c958e45fa7c01b1b3e0fb704e5b8b9eb
101061 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca
9edce7c42e6c2e8dd19788cab688cb46f779a9ec
101063 pass 835c204f1196ab8f5213a9dc5299ed76e748cdca
c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
101064 fail 835c204f1196ab8f5213a9dc5299ed76e748cdca
22857ab3492c35aac27691ae7184dcc935c5fb2a
Searching for interesting versions
Result found: flight 100769 (pass), for basis pass
Result found: flight 101015 (fail), for basis failure
Repro found: flight 101052 (pass), for basis pass
Repro found: flight 101054 (fail), for basis failure
0 revisions at 835c204f1196ab8f5213a9dc5299ed76e748cdca
c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
No revisions left to test, checking graph state.
Result found: flight 101063 (pass), for last pass
Result found: flight 101064 (fail), for first failure
Repro found: flight 101065 (pass), for last pass
Repro found: flight 101066 (fail), for first failure
Repro found: flight 101067 (pass), for last pass
Repro found: flight 101068 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 22857ab3492c35aac27691ae7184dcc935c5fb2a
Bug not present: c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/101068/
commit 22857ab3492c35aac27691ae7184dcc935c5fb2a
Author: Jan Beulich
Date: Mon Sep 19 17:50:59 2016 +0200
update Xen version to 4.5.4
Revision graph left in
/home/logs/results/bisect/xen-4.5-testing/build-i386.xen-build.{dot,ps,png,html,svg}.
101068: tolerable ALL FAIL
flight 101068 xen-4.5-testing real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/101068/
Failures :-/ but no regressions.
Tests which
Re: [Xen-devel] [Patch] x86emul: simplify prefix handling for VMFUNC
On Tue, Sep 20, 2016 at 09:50:15AM -0600, Jan Beulich wrote: > > Paul, there's been no reply to > https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg00380.html > > Jan > Jan: The refered to patch, commit a1b1572833, adds a check for vmfunc. I look a little time to look at the SDM and finally found the reference. The vmfunc can be found in Table A-6 "Opcode Extensions for One- and Two- byte Opcodes by Group Number" on page A-18 Vol. 2D of the e64-ia-32-architectures-software-developer-manual-325462.pdf. The values for vmfunc match the values in the code. I also took the liberty of looking at the other existing cases in the switch statement, and can find RDTSCP and INVLPG. The CLZERO extension value is a mystery to me. I also tried to find the original email referred to by the URL above, but could not in my mail archives. Somehow it did not get to me, so I'm replying to this email (with modified subject line) and Cc'ing Andy, Ravi, and xen-devel. -Paul ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-4.6-testing baseline-only test] 67734: tolerable FAIL
This run is configured for baseline tests only. flight 67734 xen-4.6-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67734/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-amd64-pvgrub 10 guest-start fail blocked in 67715 test-amd64-amd64-i386-pvgrub 10 guest-start fail blocked in 67715 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail blocked in 67715 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail blocked in 67715 test-amd64-amd64-xl-qemut-winxpsp3 9 windows-installfail blocked in 67715 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 67715 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 67715 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a test-xtf-amd64-amd64-3 19 xtf/test-hvm32-invlpg~shadow fail never pass test-xtf-amd64-amd64-3 26 xtf/test-hvm32pae-invlpg~shadow fail never pass test-xtf-amd64-amd64-3 34 xtf/test-hvm64-invlpg~shadow fail never pass build-i386-rumprun5 rumprun-buildfail never pass build-amd64-rumprun 5 rumprun-buildfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-xtf-amd64-amd64-1 19 xtf/test-hvm32-invlpg~shadow fail never pass test-xtf-amd64-amd64-1 26 xtf/test-hvm32pae-invlpg~shadow fail never pass test-xtf-amd64-amd64-1 34 xtf/test-hvm64-invlpg~shadow fail never pass test-xtf-amd64-amd64-2 19 xtf/test-hvm32-invlpg~shadow fail never pass test-xtf-amd64-amd64-2 26 xtf/test-hvm32pae-invlpg~shadow fail never pass test-xtf-amd64-amd64-2 34 xtf/test-hvm64-invlpg~shadow fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass version targeted for testing: xen 57dbc55cd3e239ab0ce5bdd62cf309e27fe52a1a baseline version: xen 3cffa34537767dfdb6a0fa02c1a54fdfc7644b6d Last test of basis67715 2016-09-15 02:18:46 Z5 days Testing same since67734 2016-09-20 15:45:31 Z0 days1 attempts People who touched revisions under test: Andrew Cooper M
Re: [Xen-devel] boot-wrapped xen image barfs with overlapped sections
I finally resolved this issue after hunting around. The clue comes from
this page,
https://wiki.linaro.org/LEG/Engineering/Virtualization/Xen_ARM_Guide:
/chosen/module@1/reg should match bootwrapper model.lds.
>
Basically if I increase memory region for kernel, I should also update dts
file on /chosen/module@1/reg.
Here is what in model.xen.lds. As you can see, kernel area is increased to
14MB.
OUTPUT_FORMAT("elf64-littleaarch64")
OUTPUT_ARCH(aarch64)
TARGET(binary)
INPUT(./boot.xen.o)
INPUT(Xen)
INPUT(Image)
INPUT(./fdt.dtb)
SECTIONS
{
. = 0x8000;
.text : { boot.xen.o }
. = 0x8000 + 0xfff8;
mbox = .;
.mbox : { QUAD(0x0) }
. = 0x8000 + 0xE0;
xen = .;
.xen : { Xen }
. = 0x8000 + 0x8;
kernel = .;
.kernel : { Image }
. = 0x8000 + 0x0800;
dtb = .;
.dtb : { ./fdt.dtb }
.data : { *(.data) }
.bss : { *(.bss) }
}
And here is what in foundation-v8.dts for chosen:
chosen {
#address-cells = <0x1>;
#size-cells = <0x1>;
xen,xen-bootargs = "dom0_mem=512M dom0_max_vcpus=2
dtuart=serial0 conswitch=x loglvl=all guest_loglvl=all no-bootscrub";
module@1 {
compatible = "xen,linux-zimage",
"xen,multiboot-module";
reg = <0x8008 0xe0>;
bootargs = "earlyprintk=pl011,0x1c09
console=hvc0 root=/dev/vda2 debug rw";
};
};
Kernels can be any recent 4.x kernel from torvalds, stable or linaro trees.
Now move to on to boot kernel with initrd.
Jun
On Fri, Sep 16, 2016 at 2:44 PM, Jun Sun wrote:
>
> Hi, all,
>
> I have been following the instructions at https://wiki.linaro.org/
> LEG/Engineering/Virtualization/Xen_on_ARMv8_Foundation to build xen for
> arm64.
>
> When I tried to use the latest kernel instead of v3.13 as suggested, I
> failed when building boot-wrapped image. See below.
>
> ===
> jsun@ubuntu:~/work/xen/linaro-2014-guide/boot-wrapper-aarch64$ make
> CROSS_COMPILE=aarch64-linux-gnu- FDT_SRC=foundation-v8.dts xen-system.axf
> aarch64-linux-gnu-ld -o xen-system.axf --script=model.xen.lds
> aarch64-linux-gnu-ld: section .xen loaded at
> [80a0,80ac061f]
> overlaps section .kernel loaded at [8008,80c50dff]
> Makefile:78: recipe for target 'xen-system.axf' failed
> make: *** [xen-system.axf] Error 1
> ===
>
> Obviously the issue is that linker script gives about 8.5MB space for
> kernel which is too small. If I modify the linker script to give more space
> to kernel, the xen will halt during boot up right before Dom0 starts:
>
> ==
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN) Loading kernel from boot module @ 8008
> (XEN) Allocating 1:1 mappings totalling 512MB for dom0:
> (XEN) BANK[0] 0x00a000-0x00c000 (512MB)
> (XEN) Grant table range: 0x00ffe0-0x00ffe5e000
> (XEN) Loading zImage from 8008 to a008-
> a088
> (XEN) Allocating PPI 16 for event channel interrupt
> (XEN) Loading dom0 DTB to 0xa800-0xa8000fe7
> (XEN) Std. Loglevel: All
> (XEN) Guest Loglevel: All
> (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch input
> to Xen)
> (XEN) Freed 276kB init memory.
> ==
>
> Any pointers on the right way to get modern kernel working with xen on
> ARM64?
>
> Thanks.
>
> Jun
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [ovmf baseline-only test] 67735: all pass
This run is configured for baseline tests only. flight 67735 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67735/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf b6e89910dd31e38944900ddc5cb4b86cf25241b4 baseline version: ovmf 0a92ac8802704d7281ff7b9bc00ec4f893c3ece2 Last test of basis67733 2016-09-20 11:46:17 Z0 days Testing same since67735 2016-09-20 22:21:05 Z0 days1 attempts People who touched revisions under test: Satya Yarlagadda Star Zeng Yonghong Zhu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit b6e89910dd31e38944900ddc5cb4b86cf25241b4 Author: Star Zeng Date: Wed Aug 31 14:47:36 2016 +0800 MdeModulePkg PCD: Update PCD database structure definition to match BaseTools To follow PI1.4a, BaseTools has be updated to fix artificial limitation of SkuId range. This patch is to update PCD database structure definition to match BaseTools. Note: The source code and BaseTools need to be upgraded at the same time, and if they are not upgraded at the same time, build error like below will be triggered to help user identify the problem. "Please make sure the version of PCD PEIM Service and the generated PCD PEI Database match." Cc: Liming Gao Cc: Yonghong Zhu Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng Reviewed-by: Liming Gao commit a01f68bd9bd95d6cda2ddbe469d9e82e42726208 Author: Yonghong Zhu Date: Thu Sep 1 14:36:24 2016 +0800 BaseTools: Follow PI1.4a to fix artificial limitation of PCD SkuId range Current BaseTools follow previous PI spec to use UINT8 for SkuId, to follow PI1.4a, BaseTools need to be updated to fix artificial limitation of PCD SkuId range. This patch is to update BaseTools to use UINT64 for SkuId, since the PCD database structure needs to be naturally aligned, the PCD database structure layout is adjusted to keep the natural alignment and version is updated to 6. Note: As the PCD database structure layout is adjusted, the structure definition in MdeModulePkg/Include/Guid/PcdDataBaseSignatureGuid.h and PCD drivers also need to be updated. That means the source code and BaseTools need to be upgraded at the same time, and if they are not upgraded at the same time, build error like below will be triggered to help user identify the problem. "Please make sure the version of PCD PEIM Service and the generated PCD PEI Database match." Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yonghong Zhu Reviewed-by: Liming Gao commit cd3692b11ed3c760acc1015ac19785b9a36054e8 Author: Satya Yarlagadda Date: Sat Sep 17 11:24:49 2016 +0800 IntelFsp2Pkg: Align #Pragma in UPD header files to rest of EDK2 Pkgs Changed the GenCfgOpt.py script to insert pragma pack(1) instead of pragma pack (push, 1) in the upd header files generated during fsp build. This is to align with rest of the EDKII pkgs pragma pack usage. Also, this scripts generates UnusedUpdSpace for UPD address gaps. Currently it uses UIN16/UINT32/UINT64 for 2/4/8 bytes instead of UINT8[], thus causing upd space waste to have Natural Alignment. Hence changed the script to use UINT8[] for any unusedUpd fields above 1 byte. Cc: Maurice Ma Cc: Jiewen Yao Cc: Giri P Mudusuru Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Satya Yarlagadda Reviewed-by: Jiewen Yao Reviewed-by: Giri P Mudusuru ___ Xen-devel mailing list Xen-devel@lists.xen.org http
[Xen-devel] [xen-unstable test] 101040: tolerable FAIL - PUSHED
flight 101040 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/101040/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101008 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101008 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101008 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101008 test-amd64-amd64-xl-rtds 9 debian-install fail like 101008 Tests which did not succeed, but are not blocking: test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a build-amd64-rumprun 5 rumprun-buildfail never pass build-i386-rumprun5 rumprun-buildfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass version targeted for testing: xen f1446de4ba5218a58fa2486ebe090495e0fb05c4 baseline version: xen 6559a686ae77bca2539d826120c9f3bd0d75cdf8 Last test of basis 101008 2016-09-19 01:58:31 Z1 days Failing since101012 2016-09-19 12:15:44 Z1 days3 attempts Testing same since 101020 2016-09-19 20:28:16 Z1 days2 attempts People who touched revisions under test: Andrew Cooper Daniel Kiper George Dunlap Ian Jackson Jan Beulich Julien Grall Kevin Tian Olaf Hering Paulina Szubarczyk Razvan Cojocaru Tamas K Lengyel Tamas K Lengyel Wei Liu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libv
Re: [Xen-devel] [PATCH v6 2/2] xen: move TLB-flush filtering out into populate_physmap during vm creation
> > This patch implemented parts of TODO left in commit id > > a902c12ee45fc9389eb8fe54eeddaf267a555c58 (More efficient TLB-flush > > filtering in alloc_heap_pages()). It moved TLB-flush filtering out into > > populate_physmap. Because of TLB-flush in alloc_heap_pages, it's very slow > > to create a guest with memory size of more than 100GB on host with 100+ > > cpus. > > > > > Do you have some actual numbers on how much faster after applying this > patch? > > This is mostly for writing release note etc, so it is fine if you don't > have numbers at hand. I do not have data of upstream version at hand now. I always tested the performance of this patchset by backporting it to an Oracle VM based on a very old Xen version, before I sent out the patchset for review. The backport just involves: (1) copy & paste code, (2) change bool to bool_t and (3) change true/false to 1/0. The test machine has 8 nodes of 2048GB memory and 128 cpu. With this patchset applied, the time to re-create a VM (with 135GB memory and 12 vcpu) is reduced from 5min to 20s. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-4.5-testing test] 101045: tolerable FAIL - PUSHED
flight 101045 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/101045/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 6 xen-boot fail like 100909 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100909 test-armhf-armhf-xl-rtds 11 guest-start fail like 100909 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100909 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100909 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100909 Tests which did not succeed, but are not blocking: test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a build-i386-rumprun5 rumprun-buildfail never pass build-amd64-rumprun 5 rumprun-buildfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt-qcow2 10 guest-start fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 10 guest-start fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 10 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen e4ae4b03d35babc9624b7286f1ea4c6749bad84b baseline version: xen c18dfbb88670e9f2cabd93bbb32f661b71ffb73a Last test of basis 100909 2016-09-13 02:09:03 Z7 days Failing since101015 2016-09-19 16:13:24 Z1 days3 attempts Testing same since 101045 2016-09-20 12:58:05 Z0 days1 attempts People who touched revisions under test: Jan Beulich jobs: build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumprun fail build-i386-rumprun fail test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-qemut-rhel6hvm-amd pas
Re: [Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues
On 2016年09月20日 23:36, Jan Beulich wrote: >> The precondition of process_pending_softirq() working in the debug key >> > handler is that timer interrupt arrives on time and nmi_timer_fn() can >> > run to update nmi_timer_ticks before watchdog timeout. > Precondition? Process_pending_softirq() in debug key handler is mainly to deal with timer softirq to update nmi_timer_ticks in order to avoid NMI watchdog. If there is no timer interrupt arriving for long time, process_pending_softirq() here is meaningless and NMI watchdog still will be timeout. > >> > When a timer interrupt arrives, timer_softirq_action() will run all >> > expired timer handlers before programing next timer interrupt via >> > reprogram_timer(). If a timer handler runs too long E,G >5s(Time for >> > watchdog timeout is default to be 5s.), this will cause no timer >> > interrupt arriving within 5s and nmi_timer_fn() also won't be called. >> > Does this make sense to you? > Partly. I continue to think that the sequence > > some keyhandler > timer interrupt > keyhandler continues > keyhandler calls process_pending_softirq() > Question for your sequence is why there is timer interrupt before programing timer interrupt. Actually the sequence in this case is timer interrupt run key handlers in timer handler program next timer interrupt ... > should, among other things, result in timer_softirq_action() to get > run. And I don't see the _timer_ handler running for to long here, > only a key handler. Key handler may run a long time(E,G >5s) on machine with amount of cpus or create huge VM. If keyhandler doesn't run for long time, timer_softirq_action() would also be not necessary since the default timeout is 5s and nmi timer's interval is 1s. > Are you perhaps instead suffering from the > nested instance of timer_softirq_action() not being able to acquire > its lock? No, the serial port continues printing timer info before watchdog timeout. -- Best regards Tianyu Lan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 4/6] VMX: Make sure PI is in proper state before install the hooks
We may hit the ASSERT() in vmx_vcpu_block in the current code,
since vmx_vcpu_block() may get called before vmx_pi_switch_to()
has been installed or executed. Here We use cmpxchg to update
the NDST field, this can make sure we only update the NDST when
vmx_pi_switch_to() has not been called. So the NDST is in a
proper state in vmx_vcpu_block().
Suggested-by: Jan Beulich
Signed-off-by: Feng Wu
---
v4:
- This patch is previously called "Pause/Unpause the domain before/after
assigning PI hooks"
- Remove the pause/unpause method
- Use cmpxchg to update NDST
xen/arch/x86/hvm/vmx/vmcs.c | 13 +
xen/arch/x86/hvm/vmx/vmx.c | 27 ++-
2 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 1bd875a..e733753 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -956,16 +956,13 @@ void virtual_vmcs_vmwrite(const struct vcpu *v, u32
vmcs_encoding, u64 val)
*/
static void pi_desc_init(struct vcpu *v)
{
-uint32_t dest;
-
v->arch.hvm_vmx.pi_desc.nv = posted_intr_vector;
-dest = cpu_physical_id(v->processor);
-
-if ( x2apic_enabled )
-v->arch.hvm_vmx.pi_desc.ndst = dest;
-else
-v->arch.hvm_vmx.pi_desc.ndst = MASK_INSR(dest, PI_xAPIC_NDST_MASK);
+/*
+ * Mark NDST as invalid, then we can use this invalid value as a
+ * marker to whether update NDST or not in vmx_pi_hooks_assign().
+ */
+v->arch.hvm_vmx.pi_desc.ndst = 0xff;
}
static int construct_vmcs(struct vcpu *v)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 821cba2..09262d5 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -211,14 +211,39 @@ static void vmx_pi_list_cleanup(struct vcpu *v)
/* This function is called when pcidevs_lock is held */
void vmx_pi_hooks_assign(struct domain *d)
{
+struct vcpu *v;
+
if ( !iommu_intpost || !has_hvm_container_domain(d) )
return;
ASSERT(!d->arch.hvm_domain.vmx.vcpu_block);
-d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
+/*
+ * We carefully handle the timing here:
+ * - Install the context switch first
+ * - Then set the NDST field
+ * - Install the block and resume hooks in the end
+ *
+ * This can make sure the PI (especially the NDST feild) is
+ * in proper state when we call vmx_vcpu_block().
+ */
d->arch.hvm_domain.vmx.pi_switch_from = vmx_pi_switch_from;
d->arch.hvm_domain.vmx.pi_switch_to = vmx_pi_switch_to;
+
+for_each_vcpu ( d, v )
+{
+unsigned int dest = cpu_physical_id(v->processor);
+struct pi_desc *pi_desc = &v->arch.hvm_vmx.pi_desc;
+
+ /*
+* We don't need to update NDST if 'arch.hvm_domain.vmx.pi_switch_to'
+* already gets called
+*/
+(void)cmpxchg(&pi_desc->ndst, 0xff,
+x2apic_enabled ? dest : MASK_INSR(dest, PI_xAPIC_NDST_MASK));
+}
+
+d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
d->arch.hvm_domain.vmx.pi_do_resume = vmx_pi_do_resume;
}
--
2.1.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 3/6] VMX: Cleanup PI per-cpu blocking list when vcpu is destroyed
We should remove the vCPU from the per-cpu blocking list if it is going to be destroyed. Signed-off-by: Feng Wu --- v4: - Call vmx_pi_list_cleanup() before vmx_destroy_vmcs() xen/arch/x86/hvm/vmx/vmx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index 7305f40..821cba2 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -336,6 +336,7 @@ static void vmx_vcpu_destroy(struct vcpu *v) * separately here. */ vmx_vcpu_disable_pml(v); +vmx_pi_list_cleanup(v); vmx_destroy_vmcs(v); vpmu_destroy(v); passive_domain_destroy(v); -- 2.1.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 5/6] VT-d: No need to set irq affinity for posted format IRTE
We don't set the affinity for posted format IRTE, since the
destination of these interrupts is vCPU and the vCPU affinity
is set during vCPU scheduling.
Signed-off-by: Feng Wu
---
v4:
- Keep the construction of new_ire and only modify the hardware
IRTE when it is not in posted mode.
xen/drivers/passthrough/vtd/intremap.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/intremap.c
b/xen/drivers/passthrough/vtd/intremap.c
index bfd468b..4537714 100644
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -637,9 +637,12 @@ static int msi_msg_to_remap_entry(
remap_rte->address_hi = 0;
remap_rte->data = index - i;
-memcpy(iremap_entry, &new_ire, sizeof(struct iremap_entry));
-iommu_flush_cache_entry(iremap_entry, sizeof(struct iremap_entry));
-iommu_flush_iec_index(iommu, 0, index);
+if ( !iremap_entry->remap.p || !iremap_entry->remap.im )
+{
+memcpy(iremap_entry, &new_ire, sizeof(struct iremap_entry));
+iommu_flush_cache_entry(iremap_entry, sizeof(struct iremap_entry));
+iommu_flush_iec_index(iommu, 0, index);
+}
unmap_vtd_domain_page(iremap_entries);
spin_unlock_irqrestore(&ir_ctrl->iremap_lock, flags);
--
2.1.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 6/6] VMX: Fixup PI descritpor when cpu is offline
When cpu is offline, we need to move all the vcpus in its blocking
list to another online cpu, this patch handles it.
Signed-off-by: Feng Wu
---
v4:
- Remove the pointless check since we are in machine stop
context and no other cpus go down in parallel.
xen/arch/x86/hvm/vmx/vmcs.c | 1 +
xen/arch/x86/hvm/vmx/vmx.c| 42 +++
xen/include/asm-x86/hvm/vmx/vmx.h | 1 +
3 files changed, 44 insertions(+)
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index e733753..9f56c7c 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -578,6 +578,7 @@ void vmx_cpu_dead(unsigned int cpu)
vmx_free_vmcs(per_cpu(vmxon_region, cpu));
per_cpu(vmxon_region, cpu) = 0;
nvmx_cpu_dead(cpu);
+vmx_pi_desc_fixup(cpu);
}
int vmx_cpu_up(void)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 09262d5..ff87444 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -208,6 +208,48 @@ static void vmx_pi_list_cleanup(struct vcpu *v)
vmx_pi_list_remove(v);
}
+void vmx_pi_desc_fixup(int cpu)
+{
+unsigned int new_cpu, dest;
+unsigned long flags;
+struct arch_vmx_struct *vmx, *tmp;
+spinlock_t *new_lock, *old_lock = &per_cpu(vmx_pi_blocking, cpu).lock;
+struct list_head *blocked_vcpus = &per_cpu(vmx_pi_blocking, cpu).list;
+
+if ( !iommu_intpost )
+return;
+
+spin_lock_irqsave(old_lock, flags);
+
+list_for_each_entry_safe(vmx, tmp, blocked_vcpus, pi_blocking.list)
+{
+/*
+ * We need to find an online cpu as the NDST of the PI descriptor, it
+ * doesn't matter whether it is within the cpupool of the domain or
+ * not. As long as it is online, the vCPU will be woken up once the
+ * notification event arrives.
+ */
+new_cpu = cpumask_any(&cpu_online_map);
+new_lock = &per_cpu(vmx_pi_blocking, new_cpu).lock;
+
+spin_lock(new_lock);
+
+ASSERT(vmx->pi_blocking.lock == old_lock);
+
+dest = cpu_physical_id(new_cpu);
+write_atomic(&vmx->pi_desc.ndst,
+ x2apic_enabled ? dest : MASK_INSR(dest,
PI_xAPIC_NDST_MASK));
+
+list_move(&vmx->pi_blocking.list,
+ &per_cpu(vmx_pi_blocking, new_cpu).list);
+vmx->pi_blocking.lock = new_lock;
+
+spin_unlock(new_lock);
+}
+
+spin_unlock_irqrestore(old_lock, flags);
+}
+
/* This function is called when pcidevs_lock is held */
void vmx_pi_hooks_assign(struct domain *d)
{
diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h
b/xen/include/asm-x86/hvm/vmx/vmx.h
index 4cdd9b1..9783c70 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -569,6 +569,7 @@ void free_p2m_hap_data(struct p2m_domain *p2m);
void p2m_init_hap_data(struct p2m_domain *p2m);
void vmx_pi_per_cpu_init(unsigned int cpu);
+void vmx_pi_desc_fixup(int cpu);
void vmx_pi_hooks_assign(struct domain *d);
void vmx_pi_hooks_deassign(struct domain *d);
--
2.1.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 0/6] VMX: Properly handle pi descriptor and per-cpu blocking list
The current VT-d PI related code may operate incorrectly in the following scenarios: 1. When the last assigned device is dettached from the domain, all the PI related hooks are removed then, however, the vCPU can be blocked, switched to another pCPU, etc, all without the aware of PI. After the next time we attach another device to the domain, which makes the PI realted hooks avaliable again, the status of the pi descriptor is not true. Beside that, the blocking vcpu may still remain in the per-cpu blocking in this case. Patch [1/6] and [2/6] handle this. 2. After the domain is destroyed, the the blocking vcpu may also remain in the per-cpu blocking. Handled in patch [3/6]. 3. When IRTE is in posted mode, we don't need to set the irq affinity for it, since the destination of these interrupts is vCPU and the vCPU affinity is set during vCPU scheduling. Patch [5/6] handles this. 4. When a pCPU is unplugged, and there might be vCPUs on its list. Since the pCPU is offline, those vCPUs might not be woken up again. [6/6] addresses it. Feng Wu (6): VMX: Statically assign two PI hooks VMX: Properly handle pi when all the assigned devices are removed VMX: Cleanup PI per-cpu blocking list when vcpu is destroyed VMX: Make sure PI is in proper state before install the hooks VT-d: No need to set irq affinity for posted format IRTE VMX: Fixup PI descritpor when cpu is offline xen/arch/x86/hvm/vmx/vmcs.c| 14 ++--- xen/arch/x86/hvm/vmx/vmx.c | 105 ++--- xen/drivers/passthrough/vtd/intremap.c | 9 ++- xen/include/asm-x86/hvm/vmx/vmx.h | 1 + 4 files changed, 111 insertions(+), 18 deletions(-) -- 2.1.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 1/6] VMX: Statically assign two PI hooks
PI hooks: vmx_pi_switch_from() and vmx_pi_switch_to() are needed even when any previously assigned device is detached from the domain. Since 'SN' bit is also used to control the CPU side PI and we change the state of SN bit in these two functions, then evaluate this bit in vmx_deliver_posted_intr() when trying to deliver the interrupt in posted way via software. The problem is if we deassign the hooks while the vCPU is runnable in the runqueue with 'SN' set, all the furture notificaton event will be suppressed. This patch makes these two hooks statically assigned. Signed-off-by: Feng Wu --- v4: - Don't zap vmx_pi_switch_from() and vmx_pi_switch_to() when any previously assigned device is detached from the domain. - Comments changes. xen/arch/x86/hvm/vmx/vmx.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index 3d330b6..355936a 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -221,8 +221,6 @@ void vmx_pi_hooks_deassign(struct domain *d) ASSERT(d->arch.hvm_domain.vmx.vcpu_block); d->arch.hvm_domain.vmx.vcpu_block = NULL; -d->arch.hvm_domain.vmx.pi_switch_from = NULL; -d->arch.hvm_domain.vmx.pi_switch_to = NULL; d->arch.hvm_domain.vmx.pi_do_resume = NULL; } -- 2.1.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 2/6] VMX: Properly handle pi when all the assigned devices are removed
This patch handles some concern cases when the last assigned device
is removed from the domain. In this case we should carefully handle
pi descriptor and the per-cpu blocking list, to make sure:
- all the PI descriptor are in the right state when next time a
devices is assigned to the domain again.
- No remaining vcpus of the domain in the per-cpu blocking list.
Basically, we pause the domain before zapping the PI hooks and
removing the vCPU from the blocking list, then unpause it after
that.
Signed-off-by: Feng Wu
---
v4:
- Rename some functions:
vmx_pi_remove_vcpu_from_blocking_list() -> vmx_pi_list_remove()
vmx_pi_blocking_cleanup() -> vmx_pi_list_cleanup()
- Remove the check in vmx_pi_list_cleanup()
- Comments adjustment
xen/arch/x86/hvm/vmx/vmx.c | 33 +
1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 355936a..7305f40 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -158,14 +158,12 @@ static void vmx_pi_switch_to(struct vcpu *v)
pi_clear_sn(pi_desc);
}
-static void vmx_pi_do_resume(struct vcpu *v)
+static void vmx_pi_list_remove(struct vcpu *v)
{
unsigned long flags;
spinlock_t *pi_blocking_list_lock;
struct pi_desc *pi_desc = &v->arch.hvm_vmx.pi_desc;
-ASSERT(!test_bit(_VPF_blocked, &v->pause_flags));
-
/*
* Set 'NV' field back to posted_intr_vector, so the
* Posted-Interrupts can be delivered to the vCPU when
@@ -173,12 +171,12 @@ static void vmx_pi_do_resume(struct vcpu *v)
*/
write_atomic(&pi_desc->nv, posted_intr_vector);
-/* The vCPU is not on any blocking list. */
pi_blocking_list_lock = v->arch.hvm_vmx.pi_blocking.lock;
/* Prevent the compiler from eliminating the local variable.*/
smp_rmb();
+/* The vCPU is not on any blocking list. */
if ( pi_blocking_list_lock == NULL )
return;
@@ -198,6 +196,18 @@ static void vmx_pi_do_resume(struct vcpu *v)
spin_unlock_irqrestore(pi_blocking_list_lock, flags);
}
+static void vmx_pi_do_resume(struct vcpu *v)
+{
+ASSERT(!test_bit(_VPF_blocked, &v->pause_flags));
+
+vmx_pi_list_remove(v);
+}
+
+static void vmx_pi_list_cleanup(struct vcpu *v)
+{
+vmx_pi_list_remove(v);
+}
+
/* This function is called when pcidevs_lock is held */
void vmx_pi_hooks_assign(struct domain *d)
{
@@ -215,13 +225,28 @@ void vmx_pi_hooks_assign(struct domain *d)
/* This function is called when pcidevs_lock is held */
void vmx_pi_hooks_deassign(struct domain *d)
{
+struct vcpu *v;
+
if ( !iommu_intpost || !has_hvm_container_domain(d) )
return;
ASSERT(d->arch.hvm_domain.vmx.vcpu_block);
+/*
+ * Pausing the domain can make sure the vCPU is not
+ * running and hence calling the hooks simultaneously
+ * when deassigning the PI hooks and removing the vCPU
+ * from the blocking list.
+ */
+domain_pause(d);
+
d->arch.hvm_domain.vmx.vcpu_block = NULL;
d->arch.hvm_domain.vmx.pi_do_resume = NULL;
+
+for_each_vcpu ( d, v )
+vmx_pi_list_cleanup(v);
+
+domain_unpause(d);
}
static int vmx_domain_initialise(struct domain *d)
--
2.1.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-4.6-testing test] 101049: regressions - FAIL
flight 101049 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/101049/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-amd 11 guest-start/redhat.repeat fail REGR. vs. 101026 test-amd64-i386-xl 19 guest-start/debian.repeat fail REGR. vs. 101026 test-amd64-i386-xl-raw9 debian-di-installfail REGR. vs. 101026 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 11 guest-start fail like 101026 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101026 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101026 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101026 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101026 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a build-i386-rumprun5 rumprun-buildfail never pass build-amd64-rumprun 5 rumprun-buildfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass version targeted for testing: xen 245fa11021f8f123a82aa7e894d044d8f0ae6923 baseline version: xen 57dbc55cd3e239ab0ce5bdd62cf309e27fe52a1a Last test of basis 101026 2016-09-20 02:02:05 Z1 days Testing same since 101049 2016-09-20 16:13:11 Z0 days1 attempts People who touched revisions under test: Ian Jackson jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt
