> From: Tian, Kevin
> Sent: Friday, April 28, 2017 2:43 PM
>
> > From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> > Sent: Thursday, April 27, 2017 11:18 PM
> >
> > On 04/27/2017 11:05 AM, Jan Beulich wrote:
> > On 27.04.17 at 16:57, wrote:
> > >> On 04/27/2017 03:32 AM, Jan Beulic
On 04/28/2017 09:25 AM, Jan Beulich wrote:
On 27.04.17 at 19:31, wrote:
>> On 27/04/17 09:52, Jan Beulich wrote:
>> On 27.04.17 at 10:34, wrote:
On 27/04/2017 09:01, Jan Beulich wrote:
On 27.04.17 at 09:22, wrote:
>> --- a/xen/common/vm_event.c
>> +++ b/xen/common/
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: Thursday, April 27, 2017 11:18 PM
>
> On 04/27/2017 11:05 AM, Jan Beulich wrote:
> On 27.04.17 at 16:57, wrote:
> >> On 04/27/2017 03:32 AM, Jan Beulich wrote:
> >> On 26.04.17 at 20:50, wrote:
> On 04/26/2017 02:1
On Fri, Apr 28, 2017 at 01:59:47PM +0800, Tian, Kevin wrote:
>> From: Gao, Chao
>> Sent: Thursday, April 27, 2017 10:47 AM
>>
>> When injecting periodic timer interrupt in vmx_intr_assist(),
>> multi-read operations are done during one event delivery. For
>> example, if a periodic timer interrupt
A compile error was introduced between 4.9.20170413T172409.e412c03be2
and 4.9.20170426T155707.0a5370ee1f when gcc-4.3/4.5 is used:
[ 114s] gcc -m64 -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall
-Wstrict-prototypes -Wdeclaration-after-statement -g3 -O0
-fno-omit-frame-pointer
-D__XEN_INT
>>> On 27.04.17 at 19:31, wrote:
> On 27/04/17 09:52, Jan Beulich wrote:
> On 27.04.17 at 10:34, wrote:
>>> On 27/04/2017 09:01, Jan Beulich wrote:
>>> On 27.04.17 at 09:22, wrote:
> --- a/xen/common/vm_event.c
> +++ b/xen/common/vm_event.c
> @@ -357,6 +357,13 @@ void vm_even
>>> On 27.04.17 at 18:56, wrote:
> Now I am trying to replace single-page stuff with the multi-page one.
> Currently, with the single-page API, if map fails we always try to unmap
> already mapped pages.
>
> This is an example of generic code I am speaking about:
> ...
> for ( i = 0; i < (1 << or
> From: Gao, Chao
> Sent: Thursday, April 27, 2017 10:47 AM
>
> When injecting periodic timer interrupt in vmx_intr_assist(),
> multi-read operations are done during one event delivery. For
> example, if a periodic timer interrupt is from PIT, when set the
> corresponding bit in vIRR, the correspo
flight 107850 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107850/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-buildfail REGR. vs. 106986
build-amd64
branch xen-unstable
xenbranch xen-unstable
job build-i386-libvirt
testid libvirt-build
Tree: libvirt git://libvirt.org/libvirt.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reprodu
On 26/04/17 15:42, Boris Ostrovsky wrote:
> Recent code rework that split handling ov PV, HVM and PVH guests into
> separate files missed calling xen_smp_intr_init_pv() on CPU0.
>
> Add this call.
>
> Signed-off-by: Boris Ostrovsky
> Reported-by: Sander Eikelenboom
Reviewed-by: Juergen Gross
flight 107842 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107842/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-buildfail REGR. vs. 106986
build-amd64
We want to track why a guest was shutdown; in particular, being able
to tell the difference between a guest request (such as ACPI request)
and host request (such as SIGINT) will prove useful to libvirt.
Since all requests eventually end up changing shutdown_requested in
vl.c, the logical change is
Libvirt would like to be able to distinguish between a SHUTDOWN
event triggered solely by guest request and one triggered by a
SIGTERM or other action on the host. While qemu_kill_report() is
already able to tell whether a shutdown was triggered by a host
signal (but NOT by a host UI event, such a
flight 107826 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107826/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 107636
build-arm64-xsm
flight 107835 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107835/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-buildfail REGR. vs. 106986
build-amd64
flight 107791 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107791/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs.
107676
build-amd64
branch xen-unstable
xenbranch xen-unstable
job build-i386-xsm
testid xen-build
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: qemuu git://g
Add name=value parsing options for com1 and com2 to add flexibility
in setting register values for MMIO UART devices.
Maintain backward compatibility with previous positional parameter
specfications.
eg. com1=115200,8n1,0x3f8,4
eg. com1=115200,8n1,0x3f8,4,reg_width=4,reg_shift=2
eg. com1=baud=115
flight 107827 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107827/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-buildfail REGR. vs. 106986
build-amd64
On Wed, Apr 12, 2017 at 04:37:16PM +0100, Wei Liu wrote:
> On Thu, Mar 30, 2017 at 02:03:29AM -0400, Joshua Otto wrote:
> > I guess the way I had imagined an administrator using them would be in a
> > non-production/test environment - if they could run workloads
> > representative of their producti
This run is configured for baseline tests only.
flight 71238 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71238/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fcdb928a82c4ed3d776d05c277d5fb30f00f2120
baseline v
We now have macros in place to make it less verbose to add a scalar
to QDict and QList, so use them. To make this patch smaller to
review, a couple of subdirectories were done in earlier patches.
Patch created mechanically via:
spatch --sp-file scripts/coccinelle/qobject.cocci \
--macro-fil
We want to track why a guest was shutdown; in particular, being able
to tell the difference between a guest request (such as ACPI request)
and host request (such as SIGINT) will prove useful to libvirt.
Since all requests eventually end up changing shutdown_requested in
vl.c, the logical change is
flight 107776 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107776/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358
Regressions which are
On Thu, Apr 27, 2017 at 1:00 PM, Boris Ostrovsky
wrote:
> On 04/27/2017 12:46 PM, Andy Lutomirski wrote:
>> On Thu, Apr 27, 2017 at 6:21 AM, Boris Ostrovsky
>> wrote:
Also, this code in drop_other_mm_ref() looks dubious to me:
/* If this cpu still has a stale cr3 re
flight 107818 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107818/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-buildfail REGR. vs. 106986
build-amd64
flight 107808 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107808/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 107636
build-arm64-xsm
branch xen-unstable
xenbranch xen-unstable
job build-arm64-libvirt
testid libvirt-build
Tree: libvirt git://libvirt.org/libvirt.git
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: libvirt git
flight 107800 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107800/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fcdb928a82c4ed3d776d05c277d5fb30f00f2120
baseline version:
ovmf 227fe49d5d4fe6513fc09
flight 107753 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107753/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
On 04/27/2017 12:46 PM, Andy Lutomirski wrote:
> On Thu, Apr 27, 2017 at 6:21 AM, Boris Ostrovsky
> wrote:
>>> Also, this code in drop_other_mm_ref() looks dubious to me:
>>>
>>> /* If this cpu still has a stale cr3 reference, then make sure
>>>it has been flushed. */
>
Hello,
Please avoid top-posting.
On Thu, 27 Apr 2017, 21:33 Goel, Sameer, wrote:
> The changes at this point are similar in spirit to SMMUv2, with additions
> for ACPI parsing. I have not #def'd the platform_get functions or the dma
> allocation functions, prints et al. I have deleted out unnee
The changes at this point are similar in spirit to SMMUv2, with additions for
ACPI parsing. I have not #def'd the platform_get functions or the dma
allocation functions, prints et al. I have deleted out unneeded functions
instead of wrapping them in if 0 based on some internal review.
Your res
Libvirt would like to be able to distinguish between a SHUTDOWN
event triggered solely by guest request and one triggered by a
SIGTERM or other action on the host. While qemu_kill_report() is
already able to tell whether a shutdown was triggered by a host
signal (but NOT by a host UI event, such a
We want to track why a guest was shutdown; in particular, being able
to tell the difference between a guest request (such as ACPI request)
and host request (such as SIGINT) will prove useful to libvirt.
Since all requests eventually end up changing shutdown_requested in
vl.c, the logical change is
Hello,
On Thu, 27 Apr 2017, 20:12 Goel, Sameer, wrote:
> I am trying to port a Linux driver to Xen. After making the changes it
> seems that there are enough changes to say that this driver is different
> enough as compared to the original file. But it still has code from the
> original author t
flight 107809 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107809/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-buildfail REGR. vs. 106986
build-amd64
I am trying to port a Linux driver to Xen. After making the changes it seems
that there are enough changes to say that this driver is different enough as
compared to the original file. But it still has code from the original author
that is used as is.
Based on the CODING_STYLE document I was fo
On 27/04/17 09:52, Jan Beulich wrote:
On 27.04.17 at 10:34, wrote:
>> On 27/04/2017 09:01, Jan Beulich wrote:
>> On 27.04.17 at 09:22, wrote:
The introspection agent can reply to a vm_event faster than
vmx_vmexit_handler() can complete in some cases, where it is then
not s
Hi Julien,
I'm back with profiler results.
>> Oh, yes. Sorry I forgot this thread. Continuing on that, you said that "Now
>> profiler shows that hypervisor spends time in spinlocks and p2m code."
>>
>> Could you expand here? How the EL0 app will spend time in p2m code?
> I don't quite remember. I
Hi, Jan.
There are the questions I would like to clarify.
On Thu, Mar 23, 2017 at 2:47 PM, Oleksandr Tyshchenko
wrote:
> On Thu, Mar 23, 2017 at 11:07 AM, Jan Beulich wrote:
> On 22.03.17 at 19:01, wrote:
>>> Hi Jan
>>>
>>> On Wed, Mar 22, 2017 at 5:44 PM, Jan Beulich wrote:
>>> On 15
On Thu, Apr 27, 2017 at 6:21 AM, Boris Ostrovsky
wrote:
>
>
>> Also, this code in drop_other_mm_ref() looks dubious to me:
>>
>> /* If this cpu still has a stale cr3 reference, then make sure
>>it has been flushed. */
>> if (this_cpu_read(xen_current_cr3) ==
On Thu, Apr 27, 2017 at 03:42:09PM +0100, Ian Jackson wrote:
> (dropping Lars; CCing MAINTAINERs for affected areas.)
>
> Christian Lindig writes ("OCaml xenstore: max value size is configure to be
> 2048 bytes - consistent with C xenstore?"):
> > We recently had a case where XenServer installati
On 21/04/17 22:24, Stefano Stabellini wrote:
> On Fri, 21 Apr 2017, Julien Grall wrote:
>> Hi Volodymyr,
>>
>> On 21/04/17 18:04, Volodymyr Babchuk wrote:
>>> On 21 April 2017 at 19:47, Julien Grall wrote:
On 21/04/17 17:16, Volodymyr Babchuk wrote:
> On 21 April 2017 at 18:57, Julien Gra
flight 107799 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107799/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-buildfail REGR. vs. 106986
build-amd64
flight 107788 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107788/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 107636
build-arm64-xsm
On 04/27/2017 11:05 AM, Jan Beulich wrote:
On 27.04.17 at 16:57, wrote:
>> On 04/27/2017 03:32 AM, Jan Beulich wrote:
>> On 26.04.17 at 20:50, wrote:
On 04/26/2017 02:19 PM, Andrew Cooper wrote:
> On 26/04/17 19:11, Mohit Gambhir wrote:
>> Setting Pin Control (PC) bit (19) i
>>> On 27.04.17 at 16:57, wrote:
> On 04/27/2017 03:32 AM, Jan Beulich wrote:
> On 26.04.17 at 20:50, wrote:
>>> On 04/26/2017 02:19 PM, Andrew Cooper wrote:
On 26/04/17 19:11, Mohit Gambhir wrote:
> Setting Pin Control (PC) bit (19) in MSR_P6_EVNTSEL results in a General
> Prote
On 04/27/2017 03:32 AM, Jan Beulich wrote:
On 26.04.17 at 20:50, wrote:
>> On 04/26/2017 02:19 PM, Andrew Cooper wrote:
>>> On 26/04/17 19:11, Mohit Gambhir wrote:
Setting Pin Control (PC) bit (19) in MSR_P6_EVNTSEL results in a General
Protection Fault and thus results in a hypervi
Add handlers for accesses to the MSI-X message control field on the PCI
configuration space, and traps for accesses to the memory region that contains
the MSI-X table. This traps detect attempts from the guest to configure MSI-X
interrupts and properly sets them up.
Note that accesses to the Table
Add handlers for the MSI control, address, data and mask fields in order to
detect accesses to them and setup the interrupts as requested by the guest.
Note that the pending register is not trapped, and the guest can freely
read/write to it.
Whether Xen is going to provide this functionality to D
And mark the capability and header vPCI register initializers as high priority,
so that they are initialized first.
This is needed for MSI-X, since MSI-X needs to know the position of the BARs in
order to perform it's initialization, and in order to mask or enable the
MSI/MSI-X functionality on de
(dropping Lars; CCing MAINTAINERs for affected areas.)
Christian Lindig writes ("OCaml xenstore: max value size is configure to be
2048 bytes - consistent with C xenstore?"):
> We recently had a case where XenServer installation showed errors because the
> data stored in OCaml xenstore exceeded
And also allow it to do non-identity mappings by adding a new parameter. This
function will be needed in other parts apart from PVH Dom0 build. While there
fix the function to use gfn_t and mfn_t instead of unsigned long for memory
addresses.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc
Introduce a set of handlers that trap accesses to the PCI BARs and the command
register, in order to emulate BAR sizing and BAR relocation.
The command handler is used to detect changes to bit 2 (response to memory
space accesses), and maps/unmaps the BARs of the device into the guest p2m.
The BA
So that it can be called from outside in order to get the size of regular PCI
BARs. This will be required in order to map the BARs from PCI devices into PVH
Dom0 p2m.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
---
xen/drivers/passthrough/pci.c | 86 ++
Add traps to each capability PCI_CAP_LIST_NEXT field in order to mask them on
request.
All capabilities from the device are fetched and stored in an internal list,
that's later used in order to return the next capability to the guest. Note
that this only removes the capability from the linked list
Hello,
The following series contain an implementation of handlers for the PCI
configuration space inside of Xen. This allows Xen to detect accesses to the
PCI configuration space and react accordingly.
Although there hasn't been a lot of review on the previous version, I send this
new version bec
This functionality is going to reside in vpci.c (and the corresponding vpci.h
header), and should be arch-agnostic. The handlers introduced in this patch
setup the basic functionality required in order to trap accesses to the PCI
config space, and allow decoding the address and finding the correspo
Introduce a set of handlers for the accesses to the ECAM areas. Those areas are
setup based on the contents of the hardware MMCFG tables, and the list of
handled ECAM areas is stored inside of the hvm_domain struct.
The read/writes are forwarded to the generic vpci handlers once the address is
dec
This is part of commit "ts-openstack-deploy: set CURL_CA_BUNDLE" but
also allow pip to work when it is called via sudo without preserving the
existing environment variables.
Signed-off-by: Anthony PERARD
---
This patch is on top of your wip.openstack branch,
the whole branch can be found here:
On 04/27/2017 04:41 AM, Jan Beulich wrote:
> While the hypervisor side of commit cd91ab08ea ("x86emul: correct stub
> invocation constraints") was fine, the tools side triggered a bogus
> error with old gcc (4.3 and 4.4 at least). Use a slightly less
> appropriate variant instead, proven to be good
We recently had a case where XenServer installation showed errors because the
data stored in OCaml xenstore exceeded 2048 bytes:
[root@dt87 tmp]# xenstore-write /local/domain/1/foo $(cat /dev/zero | tr '\0' X
| dd bs=1 count=2048)
2048+0 records in
2048+0 records out
2048 bytes (2.0 kB) copied,
> Also, this code in drop_other_mm_ref() looks dubious to me:
>
> /* If this cpu still has a stale cr3 reference, then make sure
>it has been flushed. */
> if (this_cpu_read(xen_current_cr3) == __pa(mm->pgd))
> load_cr3(swapper_pg_dir);
>
>>
flight 107787 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107787/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-buildfail REGR. vs. 106986
build-amd64
flight 107731 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107731/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-buildfail REGR. vs. 107676
test-armhf-armhf-x
On Thu, Apr 27, 2017 at 10:44:26AM +0100, George Dunlap wrote:
>On Thu, Apr 27, 2017 at 1:43 AM, Chao Gao wrote:
>> On Wed, Apr 26, 2017 at 05:39:57PM +0100, George Dunlap wrote:
>>>On 26/04/17 01:52, Chao Gao wrote:
VT-d PI introduces a per-pCPU blocking list to track the blocked vCPU
r
On 17-04-27 03:39:02, Jan Beulich wrote:
> >>> On 27.04.17 at 11:30, wrote:
> > I have another solution now. We may move the psr_cos_ids[socket] restore
> > action
> > into 'psr_get_val' and only set the bit of 'dom_ids[]' in 'psr_set_val'.
> > 1. When socket is offline, the dom_ids[] is cleared.
flight 107779 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107779/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-buildfail REGR. vs. 106986
build-amd64
flight 10 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/10/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 107636
build-arm64-xsm
Hi, Ian
On Wed, Apr 26, 2017 at 1:05 PM, Ian Jackson wrote:
> Oleksandr Tyshchenko writes ("Re: [RFC PATCH 9/9] xen: Add use_iommu flag to
> createdomain domctl"):
>> On Tue, Apr 25, 2017 at 6:23 PM, Wei Liu wrote:
>> > Let me explain where I'm coming from:
>> >
>> > 1. if not populating the io
On 26/04/17 16:54, Wei Liu wrote:
> Signed-off-by: Wei Liu
> Reviewed-by: Andrew Cooper
Acked-by: George Dunlap
> ---
> Cc: Tim Deegan
> Cc: George Dunlap
> Cc: Jan Beulich
> Cc: Andrew Cooper
> ---
> xen/arch/x86/mm.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> di
On 04/27/17 12:00, Jan Beulich wrote:
On 27.04.17 at 10:34, wrote:
>> On 04/27/17 11:18, Jan Beulich wrote:
>> On 27.04.17 at 10:11, wrote:
On 04/27/17 11:01, Jan Beulich wrote:
On 27.04.17 at 09:22, wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/
At 03:23 -0600 on 27 Apr (1493263380), Jan Beulich wrote:
> ... it wouldn't better be the other way around: We use the patch
> in its current (or even v1) form, and try to do something about
> performance only if we really find a case where it matters. To be
> honest, I'm not even sure how I could
When injecting periodic timer interrupt in vmx_intr_assist(),
multi-read operations are done during one event delivery. For
example, if a periodic timer interrupt is from PIT, when set the
corresponding bit in vIRR, the corresponding RTE is accessed in
pt_update_irq(). When this function returns, i
On Thu, Apr 27, 2017 at 1:43 AM, Chao Gao wrote:
> On Wed, Apr 26, 2017 at 05:39:57PM +0100, George Dunlap wrote:
>>On 26/04/17 01:52, Chao Gao wrote:
>>> VT-d PI introduces a per-pCPU blocking list to track the blocked vCPU
>>> running on the pCPU. Theoretically, there are 32K domain on single
>>
>>> On 27.04.17 at 11:30, wrote:
> I have another solution now. We may move the psr_cos_ids[socket] restore
> action
> into 'psr_get_val' and only set the bit of 'dom_ids[]' in 'psr_set_val'.
> 1. When socket is offline, the dom_ids[] is cleared.
> 2. When socket is online, we have four places to
On 17-04-27 00:48:43, Jan Beulich wrote:
> >>> On 27.04.17 at 04:38, wrote:
> > On 17-04-26 04:04:15, Jan Beulich wrote:
> >> >>> On 20.04.17 at 07:38, wrote:
> >> > @@ -221,12 +210,17 @@ static void free_socket_resources(unsigned int
> >> > socket)
> >> > */
> >> > for ( i = 0; i < P
>>> On 27.04.17 at 10:58, wrote:
> On Tue, Apr 25, 2017 at 03:32:50AM -0600, Jan Beulich wrote:
>> >>> On 25.04.17 at 11:25, wrote:
>> > On Tue, Apr 25, 2017 at 10:09:34AM +0100, Julien Grall wrote:
>> >> My understanding is BARs may be allocated by the kernel because the
> firmware
>> >> didn't
>>> On 26.04.17 at 16:25, wrote:
> At 08:07 -0600 on 26 Apr (1493194043), Jan Beulich wrote:
>> >>> On 25.04.17 at 12:59, wrote:
>> > Hi,
>> >
>> > At 02:59 -0600 on 25 Apr (1493089158), Jan Beulich wrote:
>> >> Jann's explanation of the problem:
>> >>
>> >> "start situation:
>> >> - domain A
flight 107774 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107774/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-buildfail REGR. vs. 106986
build-amd64
Hi roger,
On Thu, 27 Apr 2017, 11:02 Roger Pau Monne, wrote:
> On Tue, Apr 25, 2017 at 03:32:50AM -0600, Jan Beulich wrote:
> > >>> On 25.04.17 at 11:25, wrote:
> > > On Tue, Apr 25, 2017 at 10:09:34AM +0100, Julien Grall wrote:
> > >> My understanding is BARs may be allocated by the kernel bec
>>> On 27.04.17 at 10:34, wrote:
> On 04/27/17 11:18, Jan Beulich wrote:
> On 27.04.17 at 10:11, wrote:
>>> On 04/27/17 11:01, Jan Beulich wrote:
>>> On 27.04.17 at 09:22, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -473,6 +473,39 @@ static bool
On Tue, Apr 25, 2017 at 03:32:50AM -0600, Jan Beulich wrote:
> >>> On 25.04.17 at 11:25, wrote:
> > On Tue, Apr 25, 2017 at 10:09:34AM +0100, Julien Grall wrote:
> >> My understanding is BARs may be allocated by the kernel because the
> >> firmware
> >> didn't do it. This is the current case on A
>>> On 27.04.17 at 10:34, wrote:
> On 27/04/2017 09:01, Jan Beulich wrote:
> On 27.04.17 at 09:22, wrote:
>>> The introspection agent can reply to a vm_event faster than
>>> vmx_vmexit_handler() can complete in some cases, where it is then
>>> not safe for vm_event_set_registers() to modify v
flight 71237 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71237/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
build-arm64 2 hosts-allocate broken never pass
build-arm64-pvops
flight 107721 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107721/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358
Tests which are faili
On 27/04/2017 09:41, Jan Beulich wrote:
> While the hypervisor side of commit cd91ab08ea ("x86emul: correct stub
> invocation constraints") was fine, the tools side triggered a bogus
> error with old gcc (4.3 and 4.4 at least). Use a slightly less
> appropriate variant instead, proven to be good en
While the hypervisor side of commit cd91ab08ea ("x86emul: correct stub
invocation constraints") was fine, the tools side triggered a bogus
error with old gcc (4.3 and 4.4 at least). Use a slightly less
appropriate variant instead, proven to be good enough to not
re-introduce the original problem: W
flight 107755 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107755/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 5 libvirt-buildfail REGR. vs. 107640
build-i386-libvirt
On 04/27/17 11:18, Jan Beulich wrote:
On 27.04.17 at 10:11, wrote:
>> On 04/27/17 11:01, Jan Beulich wrote:
>> On 27.04.17 at 09:22, wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -473,6 +473,39 @@ static bool hvm_get_pending_event(struct vcpu *v,
>>>
On 27/04/2017 09:01, Jan Beulich wrote:
On 27.04.17 at 09:22, wrote:
>> The introspection agent can reply to a vm_event faster than
>> vmx_vmexit_handler() can complete in some cases, where it is then
>> not safe for vm_event_set_registers() to modify v->arch.user_regs.
> This needs more expl
>>> On 27.04.17 at 10:07, wrote:
On 26.04.17 at 16:01, wrote:
>> On 04/25/2017 05:04 AM, Jan Beulich wrote:
>>> Stub invocations need to have the space the stub occupies as an input,
>>> to prevent the compiler from re-ordering (or omitting) writes to it.
>>>
>>> Signed-off-by: Jan Beulich
flight 107758 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107758/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 107636
build-arm64-xsm
>>> On 27.04.17 at 10:11, wrote:
> On 04/27/17 11:01, Jan Beulich wrote:
> On 27.04.17 at 09:22, wrote:
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -473,6 +473,39 @@ static bool hvm_get_pending_event(struct vcpu *v,
>>> struct x86_event *info)
>>> return hvm
On 04/27/17 11:01, Jan Beulich wrote:
On 27.04.17 at 09:22, wrote:
>> The introspection agent can reply to a vm_event faster than
>> vmx_vmexit_handler() can complete in some cases, where it is then
>> not safe for vm_event_set_registers() to modify v->arch.user_regs.
>
> This needs more exp
>>> On 26.04.17 at 16:01, wrote:
> On 04/25/2017 05:04 AM, Jan Beulich wrote:
>> Stub invocations need to have the space the stub occupies as an input,
>> to prevent the compiler from re-ordering (or omitting) writes to it.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/arch/x86/x86_emulate/x86
>>> On 27.04.17 at 09:22, wrote:
> The introspection agent can reply to a vm_event faster than
> vmx_vmexit_handler() can complete in some cases, where it is then
> not safe for vm_event_set_registers() to modify v->arch.user_regs.
This needs more explanation: I cannot see the connection between
On 27/04/2017 08:22, Razvan Cojocaru wrote:
> The introspection agent can reply to a vm_event faster than
> vmx_vmexit_handler() can complete in some cases, where it is then
> not safe for vm_event_set_registers() to modify v->arch.user_regs.
> This patch ensures that vm_event_resume() code only se
1 - 100 of 108 matches
Mail list logo
