flight 96262 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96262/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt5 libvirt-build fail REGR. vs. 87893
build-amd64-libvi
flight 96270 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96270/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 14 guest-saver
Hello Dirk,
On 26/06/2016 06:47, Dirk Behme wrote:
On 23.06.2016 17:18, Julien Grall wrote:
On 23/06/16 07:38, Dirk Behme wrote:
+uint64_t res2;
uint64_t res3;
uint64_t res4;
-uint64_t res5;
-uint32_t magic1;
-uint32_t res6;
+uint32_t
On June 24, 2016 7:46 PM, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Friday, June 24, 2016 1:52 PM
> >
> > From: Quan Xu
> >
> > a struct pci_dev* instead of SBDF is stored inside struct pci_ats_dev
> > and parameter to enable_ats_device().
> >
> > Signed-off-by: Quan Xu
>
> Can we unify t
On June 24, 2016 7:48 PM, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Friday, June 24, 2016 1:52 PM
> >
> > From: Quan Xu
> >
> > Signed-off-by: Quan Xu
> >
> > CC: Julien Grall
> > CC: Kevin Tian
> > CC: Feng Wu
> > CC: Jan Beulich
> > CC: Suravee Suthikulpanit
> > ---
> > xen/drivers
flight 96258 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96258/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 94748
test-amd64-amd64-
On June 24, 2016 7:55 PM, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Friday, June 24, 2016 1:52 PM
> > diff --git a/xen/drivers/passthrough/vtd/extern.h
> > b/xen/drivers/passthrough/vtd/extern.h
> > index 45357f2..efaff28 100644
> > --- a/xen/drivers/passthrough/vtd/extern.h
> > +++ b/xen/dr
Hi Julien,
On 26.06.2016 10:29, Julien Grall wrote:
Hello Dirk,
On 26/06/2016 06:47, Dirk Behme wrote:
On 23.06.2016 17:18, Julien Grall wrote:
On 23/06/16 07:38, Dirk Behme wrote:
+uint64_t res2;
uint64_t res3;
uint64_t res4;
-uint64_t res5;
-uint
On June 24, 2016 7:46 PM, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Friday, June 24, 2016 1:52 PM
> >
> > From: Quan Xu
> >
> > a struct pci_dev* instead of SBDF is stored inside struct pci_ats_dev
> > and parameter to enable_ats_device().
> >
> > Signed-off-by: Quan Xu
>
> Can we unify t
flight 96284 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96284/
Perfect :-)
All tests in this flight passed
version targeted for testing:
xen 8384dc2d95538c5910d98db3df3ff5448bf0af48
baseline version:
xen c6f7d21747805b5012
On Fri, Jun 24, 2016 at 8:10 PM, Tamas K Lengyel
wrote:
>
> On Jun 24, 2016 05:19, "Razvan Cojocaru"
> wrote:
> >
> > On 06/24/2016 02:05 PM, George Dunlap wrote:
> > > On Wed, Jun 22, 2016 at 12:38 PM, sepanta s
> wrote:
> > >> Hi,
> > >> Is it possible to monitor the access on the pages withp
Hi,
what exactly does this module do?
I have got about 1 million after calling this function for a domain with 1
Gigabyte ram and page size 4K. If the output of the function is the whole
gfns in a domain, shouldn't it be equal with (ram-size)/(page-size) ?
Is there any API to get the memory range
On 6/8/2016 4:11 PM, Tian, Kevin wrote:
It makes sense... I thought you used this security issue against
placing vIOMMU in Qemu, which made me a bit confused earlier. :-)
We are still thinking feasibility of some staging plan, e.g. first
implementing some vIOMMU features w/o dependency on root-c
flight 96272 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96272/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR.
vs. 94856
test-amd64
The number of mmio handlers are limited to a compile time macro
MAX_IO_HANDLER which is 16. This number is not at all sufficient
to support per CPU distributor regions. Either it needs to be
increased to a bigger number, at least CONFIG_NR_CPUS+16, or
allocate a separate memory for mmio handlers dy
The cmp_rdist() is always returning value zero irrespective of the
input Redistributor base addresses. Both the local variables 'l' and
'r' are pointing to the first argument 'a' causing the logical
expression 'l->base < r->base' always evaluated as false which is
wrong.
Signed-off-by: Shanker Don
For ACPI based XEN boot, the GICD region needs to be accessed inside
the function gicv3_acpi_init() in later pacth. There is a duplicate
panic() message, one in the DTS probe and second one in the ACPI probe
path. For these two reasons, move the code that validates the GICD base
address and does th
As the number of I/O handlers increase, the overhead associated with
linear lookup also increases. The system might have maximum of 144
(assuming CONFIG_NR_CPUS=128) mmio handlers. In worst case scenario,
it would require 144 iterations for finding a matching handler. Now
it is time for us to chang
The macro MAX_RDIST_COUNT is not being used after converting code
to handle number of redistributor dynamically. So remove it from
header file and the two other panic() messages that are not valid
anymore.
Signed-off-by: Shanker Donthineni
---
xen/arch/arm/gic-v3.c | 8
xen/include/
The number of Re-distributor regions allowed for dom0 is hardcoded
to a compile time macro MAX_RDIST_COUNT which is 4. On some systems,
especially latest server chips might have more than 4 redistributors.
Either we have to increase MAX_RDIST_COUNT to a bigger number or
allocate memory based on num
Record the number of mmio handlers that are required for vGICv3/2
in variable 'arch_domain.vgic.mmio_count' in vgic_v3/v2_init().
Augment this variable number to a fixed number MAX_IO_HANDLER and
pass it to domain_io_init() to allocate enough memory for handlers.
New code path:
domain_vgic_regist
Add a new function for parsing GICR subtable and move the code
that is specific to GICR table to new function without changing
the function gicv3_acpi_init() behavior.
Signed-off-by: Shanker Donthineni
---
Changes since v1:
Removed the unnecessary GICR ioremap operation inside GICR table parse
The redistributor address can be specified either as part of GICC or
GICR subtable depending on the power domain. The current driver
doesn't support parsing redistributor entry that is defined in GICC
subtable. The GIC CPU subtable entry holds the associated Redistributor
base address if it is not
Separate the code logic that does the registration of vgic_v3/v2 ops
to a new fucntion domain_vgic_register(). The intention of this
separation is to record the required mmio count in vgic_v3/v2_init()
and pass it to function domain_io_init() in the later patch.
Signed-off-by: Shanker Donthineni
The current driver doesn't support parsing Redistributor entries that
are described in the MADT GICC table. Not all the GIC implementors
places the Redistributor regions in the always-on power domain. On
systems, the UEFI firmware should describe Redistributor base address
in the associated GIC CPU
flight 96275 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96275/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-build fail REGR. vs. 80927
build-i
flight 96279 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96279/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt5 libvirt-build fail REGR. vs. 87893
build-amd64-libvi
On 26/06/2016 10:30, Dirk Behme wrote:
Hi Julien,
Hi Dirk,
On 26.06.2016 10:29, Julien Grall wrote:
Hello Dirk,
On 26/06/2016 06:47, Dirk Behme wrote:
On 23.06.2016 17:18, Julien Grall wrote:
On 23/06/16 07:38, Dirk Behme wrote:
+uint64_t res2;
uint64_t res3;
flight 96278 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96278/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-libvirt-vhd 10 guest-start fail pass in 96251
Regressions which are regarded as
flight 96290 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96290/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-build fail REGR. vs. 80927
build-i
Sorry for the precedent post that was written a bit too fast. Libreboot was
flashed when I wrote it, which is the equivalent of a having vt-d
deactivated (iommu=0). Thanks to a user that read this post and wrote to me
personally so I could do my mea culpa. Sorry for the precedent misleading
post.
Sorry for the precedent post that was written a bit too fast. Libreboot was
flashed when I wrote it, which is the equivalent of a having vt-d
deactivated (iommu=0). Thanks to a user that read this post and wrote to me
personally so I could do my mea culpa. Sorry for the precedent misleading
post.
flight 96291 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96291/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt5 libvirt-build fail REGR. vs. 87893
build-amd64-libvi
On 2016/6/24 0:26, Julien Grall wrote:
> On 23/06/16 04:16, Shannon Zhao wrote:
>> From: Shannon Zhao
>>
>> Construct GTDT table with the interrupt information of timers.
>>
>> Signed-off-by: Shannon Zhao
>> ---
>> tools/libxl/libxl_arm_acpi.c | 28
>> 1 file cha
On 2016/6/24 0:42, Julien Grall wrote:
>
>
> On 23/06/16 15:50, Stefano Stabellini wrote:
>> On Thu, 23 Jun 2016, Shannon Zhao wrote:
>>> diff --git a/tools/libxl/libxl_empty_dsdt_arm.asl
>>> b/tools/libxl/libxl_empty_dsdt_arm.asl
>>> new file mode 100644
>>> index 000..005fa6a
>>> --- /dev
I wanted some elaboration on this question and answer posted recently.
On 06/13/2016 01:43 PM, Meng Xu wrote:
>> Hi,
>>
>> I have a quick question about using the Linux spin_lock() in Xen
>> environment to protect some host-wide shared (memory) resource among
>> VMs.
>>
>> *** The question is as f
flight 96282 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96282/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 94748
test-amd64-amd64-
flight 96293 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96293/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-build fail REGR. vs. 80927
build-i
On 2016/6/24 1:03, Julien Grall wrote:
> Hi Shannon,
>
> On 23/06/16 04:16, Shannon Zhao wrote:
>
> [...]
>
>> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
>> index 264b6ef..5347480 100644
>> --- a/tools/libxl/Makefile
>> +++ b/tools/libxl/Makefile
>> @@ -77,7 +77,29 @@ endif
>>
>>
On 2016/6/24 2:46, Julien Grall wrote:
>> +
>> static int alloc_magic_pages(struct xc_dom_image *dom)
>> {
> > int rc, i;
>> @@ -100,6 +141,16 @@ static int alloc_magic_pages(struct xc_dom_image
>> *dom)
>> xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_STORE_EVTCHN,
>>
40 matches
Mail list logo
