flight 35226 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35226/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 3 host-install(3) broken REGR. vs. 341
On 02/19/2015 06:44 PM, David Vrabel wrote:
On 18/02/2015 06:52, Juergen Gross wrote:
With adapting the memory layout of dom0 to that of the host care must
be taken not to remap the initial p2m list supported by the hypervisor.
"...supplied by the hypervisor" ?
Yes, of course.
If the p2m
On 02/19/2015 06:37 PM, David Vrabel wrote:
On 18/02/2015 06:52, Juergen Gross wrote:
Check whether the page tables built by the domain builder are at
memory addresses which are in conflict with the target memory map.
If this is the case just panic instead of running into problems
later.
Aga
On 02/19/2015 07:07 PM, David Vrabel wrote:
On 18/02/2015 06:51, Juergen Gross wrote:
Currently especially for dom0 guest memory with guest pfns not
matching host areas populated with RAM are remapped to areas which
are RAM native as well. This is done to be able to use identity
mappings (pfn ==
flight 35182 ovmf real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35182/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64 5 xen-boot fail REGR. vs. 33686
test-amd64-i386-pair 17 gu
flight 35087 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35087/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 3 host-install(3) broken REGR. vs. 33488
build-armh
Hi Ian,
On 23/02/2015 14:45, Ian Campbell wrote:
+is the absolute path in the device tree.
Can it be an alias?
Right now, no. But I can change it if you think it's useful.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.o
I think the title of the commit message is misleading.
I gave the impression that we don't want to parse the PSCI-0.2 for Xen,
which is obviously wrong.
A better title would be: "Don't pass the PSCI-0.2 node to the DOM0"
On 23/02/2015 17:52, Ian Campbell wrote:
On Wed, 2015-02-18 at 17:49 +0
On 18 February 2015 at 08:37, Ard Biesheuvel wrote:
> On 17 February 2015 at 18:40, Jordan Justen wrote:
>> Ard,
>>
>> For the subject, I think
>> MdePkg/BaseSynchronizationLib: Add InterlockedCompareExchange16
>> would be better.
>>
>
> OK
>
>> Acked-by: Jordan Justen
>>
>
> Thanks
>
>> Thanks
On 23/02/15 16:19, Wei Liu wrote:
> On Mon, Feb 23, 2015 at 09:18:49AM +, Ross Lagerwall wrote:
>> Don't kill xenstored as part of the usual service shutdown process to
>> prevent hangs on shutdown where the kernel tries to unplug a VIF
>> after xenstored has exited.
>>
>> Signed-off-by: Ross L
On 23/02/15 16:47, Jan Beulich wrote:
On 23.02.15 at 17:37, wrote:
>> On 23/02/15 15:39, Ian Campbell wrote:
>>> On Mon, 2015-02-23 at 10:20 +, Jan Beulich wrote:
>>> On 23.02.15 at 11:10, wrote:
> Right now, there is no possibility to reset a platform device in the
> kernel
On 02/23/2015 11:44 AM, Ian Campbell wrote:
On Mon, 2015-02-09 at 15:04 -0500, Boris Ostrovsky wrote:
What is the rationale for this change?
libxl is not the right place to handle hypervisor-specific details like
buffer management (most, if not all, of other services that libxl
provides push
On Mon, 2015-02-23 at 16:01 +, Julien Grall wrote:
> Hi Ian,
>
> On 23/02/15 15:30, Ian Campbell wrote:
> > On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> >
> >> +/* This limit is used by the hypercalls to restrict the size of the path
> >> */
> >> +#define DEVICE_TREE_MAX_PATHLEN
On 02/20/2015 12:17 PM, Ian Campbell wrote:
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
TODO: Update the commit message
A device node is described by a path. It will be used to retrieved the
node in the device tree and assign the related device to the domain.
Only device protected b
>>> On 23.02.15 at 16:39, wrote:
> On Mon, 2015-02-23 at 10:20 +, Jan Beulich wrote:
>> >>> On 23.02.15 at 11:10, wrote:
>> > Hi Jan,
>> >
>> > On 23/02/2015 09:40, Jan Beulich wrote:
>> > On 20.02.15 at 18:04, wrote:
>> >>> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
>>
>>> On 23.02.15 at 17:03, wrote:
> On 02/23/15 10:05, Jan Beulich wrote:
> On 17.02.15 at 00:05, wrote:
>>> This includes adding is_vmware_port_enabled
>>>
>>> This is a new domain_create() flag, DOMCRF_vmware_port. It is
>>> passed to domctl as XEN_DOMCTL_CDF_vmware_port.
>>
>> As indicate
>>> On 23.02.15 at 16:33, wrote:
> On Mon, 2015-02-23 at 09:37 +, Jan Beulich wrote:
>> >>> On 20.02.15 at 18:46, wrote:
>> > On 20/02/15 17:03, Ian Campbell wrote:
>> >> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
>> >>
>> >> Subject: "release the DT devices assigned to a guest e
On 23/02/15 16:09, Vijay Kilari wrote:
> On Mon, Feb 23, 2015 at 9:10 PM, Julien Grall wrote:
>> Hello Vijay,
>>
>> On 23/02/15 13:04, Vijay Kilari wrote:
>>> On Thu, Feb 19, 2015 at 7:33 PM, Julien Grall
>>> wrote:
On 19/02/15 07:17, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
On Mon, Feb 23, 2015 at 09:18:49AM +, Ross Lagerwall wrote:
> Don't kill xenstored as part of the usual service shutdown process to
> prevent hangs on shutdown where the kernel tries to unplug a VIF
> after xenstored has exited.
>
> Signed-off-by: Ross Lagerwall
Do you run xendomains service
On Fri, 2015-02-13 at 13:09 +, Wei Liu wrote:
> On Mon, Feb 02, 2015 at 04:06:09PM +0800, Chao Peng wrote:
> > +#ifdef LIBXL_HAVE_PSR_MBM
> > +int libxl_psr_cmt_type_supported(libxl_ctx *ctx, libxl_psr_cmt_type type);
> > +int libxl_psr_cmt_get_mem_bandwidth_sample(libxl_ctx *ctx,
> > +
>>> On 23.02.15 at 16:46, wrote:
> On Mon, 2015-02-23 at 15:27 +, Jan Beulich wrote:
>> >>> On 23.02.15 at 16:02, wrote:
>> > Is the reason for the scan being of segment 0 only is that it is the one
>> > which lives at the legacy PCI CFG addresses (or those magic I/O ports)?
>>
>> Right - i
>>> On 23.02.15 at 16:53, wrote:
> Hi Ian,
>
> On 23/02/15 15:28, Ian Campbell wrote:
>> On Mon, 2015-02-23 at 09:33 +, Jan Beulich wrote:
>> On 20.02.15 at 17:53, wrote:
Jan, do you have any feeling for how this is going to play out on x86
with the vapic stuff?
>>>
>>> The vap
On 02/23/2015 11:09 AM, Andy Lutomirski wrote:
On Mon, Feb 23, 2015 at 8:01 AM, Boris Ostrovsky
wrote:
Commit 1e02ce4cccdc ("x86: Store a per-cpu shadow copy of CR4")
introduced CR4 shadows.
These shadows are initialized in early boot code. The commit missed
initialization for 64-bit PV(H) gu
On 23/02/15 16:04, Ian Campbell wrote:
> On Mon, 2015-02-23 at 15:53 +, Julien Grall wrote:
>> Hi Ian,
>>
>> On 23/02/15 15:28, Ian Campbell wrote:
>>> On Mon, 2015-02-23 at 09:33 +, Jan Beulich wrote:
>>> On 20.02.15 at 17:53, wrote:
> Jan, do you have any feeling for how this is
When the hypervisor is booted with an XSM policy containing an error
(such as a mismatched permission value), this error is mostly ignored
during boot. This causes FLASK to suspend security policy enforcement
until a policy is loaded, effectively allowing all access.
This patch adds a call to pan
On 02/23/2015 10:04 AM, Julien Grall wrote:
Hi Daniel,
On 20/02/15 23:01, Daniel De Graaf wrote:
On 02/20/2015 10:58 AM, Julien Grall wrote:
Each class can contains 32 permisions which are encoded on a word (one
bit per permission).
Currently the awk script will generate an hexadecimal value
On Mon, 2015-02-23 at 15:53 +, Julien Grall wrote:
> Hi Ian,
>
> On 23/02/15 15:28, Ian Campbell wrote:
> > On Mon, 2015-02-23 at 09:33 +, Jan Beulich wrote:
> > On 20.02.15 at 17:53, wrote:
> >>> Jan, do you have any feeling for how this is going to play out on x86
> >>> with the vap
On Mon, 2015-02-23 at 15:54 +, Julien Grall wrote:
> On 23/02/15 15:52, Ian Campbell wrote:
> > On Mon, 2015-02-23 at 15:47 +, Julien Grall wrote:
> >> Hi Ian,
> >>
> >> On 23/02/15 15:20, Ian Campbell wrote:
> >>> On Fri, 2015-02-20 at 17:28 +, Julien Grall wrote:
> The priority i
On Mon, Feb 23, 2015 at 8:01 AM, Boris Ostrovsky
wrote:
> Commit 1e02ce4cccdc ("x86: Store a per-cpu shadow copy of CR4")
> introduced CR4 shadows.
>
> These shadows are initialized in early boot code. The commit missed
> initialization for 64-bit PV(H) guests that this patch adds.
Whoops, worry.
Hi Julien,
On Mon, Feb 23, 2015 at 9:10 PM, Julien Grall wrote:
> Hello Vijay,
>
> On 23/02/15 13:04, Vijay Kilari wrote:
>> On Thu, Feb 19, 2015 at 7:33 PM, Julien Grall
>> wrote:
>>> On 19/02/15 07:17, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K
For arm memory for 1024
Commit 1e02ce4cccdc ("x86: Store a per-cpu shadow copy of CR4")
introduced CR4 shadows.
These shadows are initialized in early boot code. The commit missed
initialization for 64-bit PV(H) guests that this patch adds.
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/enlighten.c |1 +
1 files
On Mon, 2015-02-23 at 15:51 +, Julien Grall wrote:
> On 20/02/15 16:53, Ian Campbell wrote:
> > Are we absolutely 100% sure that we will never ever want to map hardware
> > IRQs to guests on ARMs using pirq-type event channels? Because that is
> > what we are essentially ruling out here.
>
>
Hi Ian,
On 23/02/15 15:31, Ian Campbell wrote:
> On Fri, 2015-02-20 at 17:45 +, Julien Grall wrote:
>> On 20/02/15 16:58, Ian Campbell wrote:
>>> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
This new function will correctly initialize the IOMMU page table for the
current do
On 02/23/15 10:05, Jan Beulich wrote:
On 17.02.15 at 00:05, wrote:
>> This includes adding is_vmware_port_enabled
>>
>> This is a new domain_create() flag, DOMCRF_vmware_port. It is
>> passed to domctl as XEN_DOMCTL_CDF_vmware_port.
>
> As indicated before, I don't think this is a good use
Hi Ian,
On 23/02/15 15:30, Ian Campbell wrote:
> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
>
>> +/* This limit is used by the hypercalls to restrict the size of the path */
>> +#define DEVICE_TREE_MAX_PATHLEN 1024
>
> Is this something you've made up or derived from the DT spec/ePAP
On Mon, 2015-02-23 at 15:48 +, Andrew Cooper wrote:
> GIC version and SPIs should absolutely be part of the migration stream.
> They are domain architectural state.
Of course, the question is where.
They could be part of the Xen hvmsave blob for the GIC (i.e. along with
the other GIC archite
Hi Ian,
On 20/02/15 16:55, Ian Campbell wrote:
> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
>> There is no reason to use signed integer for an index.
>
> Did you check for now pointless "if ( uthing < 0 ) which a picky
> compiler might whinge about?
I just checked and we don't have a
Not an expert on scheduler, so bear with me if my questions / comments
are stupid.
On Sat, Feb 21, 2015 at 10:51:59AM -0500, Meng Xu wrote:
> Hi all,
>
> This is for Xen 4.6: Enabling XL to set the parameters of each
> individual VCPU of a domain for RTDS scheduler.
>
> [Goal]
> Right now, xl sc
On 23/02/15 15:52, Ian Campbell wrote:
> On Mon, 2015-02-23 at 15:47 +, Julien Grall wrote:
>> Hi Ian,
>>
>> On 23/02/15 15:20, Ian Campbell wrote:
>>> On Fri, 2015-02-20 at 17:28 +, Julien Grall wrote:
The priority is controlled by route_irq_to_guest and set statically
using GIC_
Hi Ian,
On 23/02/15 15:28, Ian Campbell wrote:
> On Mon, 2015-02-23 at 09:33 +, Jan Beulich wrote:
> On 20.02.15 at 17:53, wrote:
>>> Jan, do you have any feeling for how this is going to play out on x86
>>> with the vapic stuff?
>>
>> The vapic logic shouldn't require any physdevop invol
On Mon, 2015-02-23 at 15:47 +, Julien Grall wrote:
> Hi Ian,
>
> On 23/02/15 15:20, Ian Campbell wrote:
> > On Fri, 2015-02-20 at 17:28 +, Julien Grall wrote:
> >> The priority is controlled by route_irq_to_guest and set statically
> >> using GIC_PRI_IRQ.
> >>
> >> If we decide to hardcode
Hi Ian,
On 20/02/15 16:53, Ian Campbell wrote:
> On Thu, 2015-01-29 at 12:33 +, Stefano Stabellini wrote:
>> On Thu, 29 Jan 2015, Julien Grall wrote:
>>> On 29/01/15 12:17, Stefano Stabellini wrote:
On Wed, 28 Jan 2015, Julien Grall wrote:
> Hi Stefano,
>
> On 28/01/15 18:52,
Hi Ian,
On 23/02/15 15:25, Ian Campbell wrote:
> On Fri, 2015-02-20 at 17:41 +, Julien Grall wrote:
>
+/* TODO: Handle eviction from LRs. For now, deny remove if the IRQ
+ * is inflight and not disabled.
>>>
>>> If we are ungracefully killing a guest doesn't this risk ending
On 20/02/15 15:15, Ian Campbell wrote:
> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
>> On ARM the virtual GIC may differ between each guest (emulated GIC version,
>> number of SPIs...). Those informations are already known at the domain
>> creation
> "This information is already known
Hi Ian,
On 23/02/15 15:22, Ian Campbell wrote:
> On Fri, 2015-02-20 at 17:29 +, Julien Grall wrote:
>> On 20/02/15 16:08, Ian Campbell wrote:
>>> On Wed, 2015-01-28 at 18:26 +, Stefano Stabellini wrote:
>>>
> +int spi = irq - 32;
unsigned int
>>>
>>> and underflow?
>>
On Mon, Feb 23, 2015 at 03:13:48PM +, Dario Faggioli wrote:
> Hi everyone,
>
> On Thu, 2015-02-19 at 17:01 +, Mel Gorman wrote:
> > On Thu, Feb 19, 2015 at 01:06:53PM +, David Vrabel wrote:
>
> > I cannot think of a reason why this would fail for NUMA balancing on bare
> > metal. The
Hi Ian,
On 23/02/15 15:20, Ian Campbell wrote:
> On Fri, 2015-02-20 at 17:28 +, Julien Grall wrote:
>> The priority is controlled by route_irq_to_guest and set statically
>> using GIC_PRI_IRQ.
>>
>> If we decide to hardcoded the priority here, we should drop the
>> parameter on gic_route_irq_g
On Mon, 2015-02-23 at 15:27 +, Jan Beulich wrote:
> >>> On 23.02.15 at 16:02, wrote:
> > On Mon, 2015-02-23 at 14:45 +, Jan Beulich wrote:
> >> In which case the Dom0 OS doing so would need to communicate
> >> its decisions to the hypervisor, as you suggest further down.
> >
> > So more c
On 23/02/15 15:15, Ian Campbell wrote:
> On Fri, 2015-02-20 at 17:03 +, Julien Grall wrote:
>> On 20/02/15 15:42, Ian Campbell wrote:
>>> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
@@ -919,8 +943,14 @@ static int make_timer_node(const struct domain *d,
void *fdt,
Hi Charles,
It's good to see that someone else is tackling this problem. We have a similar
problem in XenServer; tapdisk3 is a user space backend (just like qemu-qdisk)
and therefore libxenstat is unable to pick up any statistics from it. In that
way, "xentop" also doesn't display any stats for
Hi Ian,
On 23/02/15 15:12, Ian Campbell wrote:
> On Fri, 2015-02-20 at 17:01 +, Julien Grall wrote:
diff --git a/docs/misc/arm/device-tree/passthrough.txt
b/docs/misc/arm/device-tree/passthrough.txt
new file mode 100644
index 000..04645b3
--- /dev/null
+++ b/
Hello Vijay,
On 23/02/15 13:04, Vijay Kilari wrote:
> On Thu, Feb 19, 2015 at 7:33 PM, Julien Grall wrote:
>> On 19/02/15 07:17, vijay.kil...@gmail.com wrote:
>>> From: Vijaya Kumar K
>>>
>>> For arm memory for 1024 irq descriptors are allocated
>>> statically irrespective of number of interrupt
On Mon, 2015-02-23 at 10:20 +, Jan Beulich wrote:
> >>> On 23.02.15 at 11:10, wrote:
> > Hi Jan,
> >
> > On 23/02/2015 09:40, Jan Beulich wrote:
> > On 20.02.15 at 18:04, wrote:
> >>> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> Currently, when the device is deassigned f
On Mon, 2015-02-23 at 10:10 +, Julien Grall wrote:
>
> On 20/02/2015 17:04, Ian Campbell wrote:
> > On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> >> Currently, when the device is deassigned from a domain, we directly
> >> reassign
> >> to DOM0.
> >>
> >> As the device may not have
On Mon, 2015-02-23 at 09:37 +, Jan Beulich wrote:
> >>> On 20.02.15 at 18:46, wrote:
> > On 20/02/15 17:03, Ian Campbell wrote:
> >> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> >>
> >> Subject: "release the DT devices assigned to a guest earlier"
> >>
> >>> The toolstack may not
On Fri, 2015-02-20 at 17:45 +, Julien Grall wrote:
> On 20/02/15 16:58, Ian Campbell wrote:
> > On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> >> This new function will correctly initialize the IOMMU page table for the
> >> current domain.
> >>
> >> Also use it in iommu_assign_dt_devi
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> +/* This limit is used by the hypercalls to restrict the size of the path */
> +#define DEVICE_TREE_MAX_PATHLEN 1024
Is this something you've made up or derived from the DT spec/ePAPR etc?
Apart from this the patch seems fine, clarifying t
On Fri, 2015-02-20 at 17:43 +, Julien Grall wrote:
> On 20/02/15 16:56, Ian Campbell wrote:
> > On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> >> Signed-off-by: Julien Grall
> >
> > Is this function still needed in the new model which doesn't do
> > automatic mappings etc?
>
> It's
On Mon, 2015-02-23 at 09:33 +, Jan Beulich wrote:
> >>> On 20.02.15 at 17:53, wrote:
> > Jan, do you have any feeling for how this is going to play out on x86
> > with the vapic stuff?
>
> The vapic logic shouldn't require any physdevop involvement, so if
> I read right what you propose (not
>>> On 23.02.15 at 16:02, wrote:
> On Mon, 2015-02-23 at 14:45 +, Jan Beulich wrote:
>> In which case the Dom0 OS doing so would need to communicate
>> its decisions to the hypervisor, as you suggest further down.
>
> So more concretely something like:
> #define PHYSDEVOP_pci_host_bri
On Fri, 2015-02-20 at 17:41 +, Julien Grall wrote:
> >> +/* TODO: Handle eviction from LRs. For now, deny remove if the IRQ
> >> + * is inflight and not disabled.
> >
> > If we are ungracefully killing a guest doesn't this risk ending up with
> > an undestroyable domain? i.e. if the g
On Fri, 2015-02-20 at 17:29 +, Julien Grall wrote:
> On 20/02/15 16:08, Ian Campbell wrote:
> > On Wed, 2015-01-28 at 18:26 +, Stefano Stabellini wrote:
> >
> >>> +int spi = irq - 32;
> >>
> >> unsigned int
> >
> > and underflow?
>
> No because there is a check (irq < 32) before
On Fri, 2015-02-20 at 17:28 +, Julien Grall wrote:
> Hi Ian,
>
> On 20/02/15 16:07, Ian Campbell wrote:
> > More importantly: We have (hopefully) guaranteed elsewhere that an PPI
> > or SGI can never make it here, I take it. If that's the case then either
> > the comment should say that, or mo
On Thu, Feb 12, 2015 at 07:19:15PM +0800, Ard Biesheuvel wrote:
> This patch updates XenBusDxe to use the 16-bit compare and exchange
> function that was introduced for this purpose to the
> BaseSynchronizationLib. It also provides a new generic implementation
> of TestAndClearBit () using the same
On Wed, Feb 11, 2015 at 10:18:18AM -0700, Jim Fehlig wrote:
> Wei Liu wrote:
> > On Tue, Feb 10, 2015 at 11:01:46AM +, Ian Jackson wrote:
> >
> >> Wei Liu writes ("[PATCH 3/3] libxl: libxl__device_from_disk should
> >> retrieve backend from xenstore"):
> >>
> >>> ... if backend is not
On Fri, 2015-02-20 at 17:03 +, Julien Grall wrote:
> On 20/02/15 15:42, Ian Campbell wrote:
> > On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> >> @@ -919,8 +943,14 @@ static int make_timer_node(const struct domain *d,
> >> void *fdt,
> >> return res;
> >> }
> >>
> >> -/* Map
On Fri, 2015-02-20 at 17:01 +, Julien Grall wrote:
> >> diff --git a/docs/misc/arm/device-tree/passthrough.txt
> >> b/docs/misc/arm/device-tree/passthrough.txt
> >> new file mode 100644
> >> index 000..04645b3
> >> --- /dev/null
> >> +++ b/docs/misc/arm/device-tree/passthrough.txt
> >> @@
On 23/02/15 11:50, Manish Jaggi wrote:
>
> On 23/02/15 4:44 pm, Julien Grall wrote:
>>
>>
>> On 23/02/2015 10:59, Manish Jaggi wrote:
>>>
>>> On 20/02/15 8:09 pm, Ian Campbell wrote:
On Fri, 2015-02-20 at 19:44 +0530, Manish Jaggi wrote:
>> Another option might be a new hypercall (assumin
>>> On 23.02.15 at 15:53, wrote:
> On 02/23/2015 09:47 AM, Jan Beulich wrote:
> On 23.02.15 at 15:42, wrote:
>>> On 02/23/2015 04:57 AM, Jan Beulich wrote:
>>> On 21.02.15 at 19:14, wrote:
> --- a/xen/arch/x86/srat.c
> +++ b/xen/arch/x86/srat.c
> @@ -21,44 +21,55 @@
>
On Fri, 2015-02-20 at 16:09 +, Julien Grall wrote:
> Hi Ian,
>
> On 20/02/15 15:15, Ian Campbell wrote:
> > On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> >> On ARM the virtual GIC may differ between each guest (emulated GIC version,
> >> number of SPIs...). Those informations are al
Hi everyone,
On Thu, 2015-02-19 at 17:01 +, Mel Gorman wrote:
> On Thu, Feb 19, 2015 at 01:06:53PM +, David Vrabel wrote:
> I cannot think of a reason why this would fail for NUMA balancing on bare
> metal. The PAGE_NONE protection clears the present bit on p[te|md]_modify
> so the expect
>>> On 17.02.15 at 00:05, wrote:
> Enable no-fault of pio in x86_emulate for VMware port
???
> @@ -393,6 +393,11 @@ struct x86_emulate_ops
> enum x86_segment seg,
> unsigned long offset,
> struct x86_emulate_ctxt *ctxt);
> +
> +/* vmport_check */
> +int (*vmpor
Hi Daniel,
On 20/02/15 23:01, Daniel De Graaf wrote:
> On 02/20/2015 10:58 AM, Julien Grall wrote:
>> Each class can contains 32 permisions which are encoded on a word (one
>> bit per permission).
>>
>> Currently the awk script will generate an hexadecimal value for each
>> permission. This may re
>>> On 17.02.15 at 00:05, wrote:
> This includes adding is_vmware_port_enabled
>
> This is a new domain_create() flag, DOMCRF_vmware_port. It is
> passed to domctl as XEN_DOMCTL_CDF_vmware_port.
As indicated before, I don't think this is a good use case for a
domain creation flag. Some of the o
On Mon, 2015-02-23 at 14:45 +, Jan Beulich wrote:
> >>> On 23.02.15 at 15:33, wrote:
> > On Mon, 2015-02-23 at 14:07 +, Jan Beulich wrote:
> >> >>> On 23.02.15 at 13:45, wrote:
> >> > In which case might we be at liberty to specify that on ARM+Device Tree
> >> > systems (i.e. those where
On 02/23/2015 09:47 AM, Jan Beulich wrote:
On 23.02.15 at 15:42, wrote:
On 02/23/2015 04:57 AM, Jan Beulich wrote:
On 21.02.15 at 19:14, wrote:
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -21,44 +21,55 @@
#include
#include
+#define MAX_PXM 255
Perhaps better (MAX_N
On Sun, 2015-02-22 at 00:31 -0500, Dagaen Golomb wrote:
> Hello everyone,
>
Hello,
> I'd like to solicit comments on improvements to the RTDS scheduler for
> Xen 4.6.
>
My first comment is that I'm happy that you guys are working on
this! :-)
> [Motivation]
>
> This change will increase the eff
>>> On 23.02.15 at 15:42, wrote:
> On 02/23/2015 04:57 AM, Jan Beulich wrote:
> On 21.02.15 at 19:14, wrote:
>>> --- a/xen/arch/x86/srat.c
>>> +++ b/xen/arch/x86/srat.c
>>> @@ -21,44 +21,55 @@
>>> #include
>>> #include
>>>
>>> +#define MAX_PXM 255
>> Perhaps better (MAX_NUMNODES -
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> The option "dtdev" will be used to passthrough a non-PCI device described
> in the device tree to a guest.
>
> Signed-off-by: Julien Grall
> Cc: Ian Jackson
> Cc: Wei Liu
>
> ---
> Changes in v2:
> - libxl_device_dt has been
On Thu, 2015-01-29 at 15:06 +, Stefano Stabellini wrote:
> I don't think it is necessary to have two separate patches, but let's
> see what the libxl maintainers have to say.
For large changes having the split between introducing libxl side and
then using it can be useful, but this change is s
>>> On 23.02.15 at 15:33, wrote:
> On Mon, 2015-02-23 at 14:07 +, Jan Beulich wrote:
>> >>> On 23.02.15 at 13:45, wrote:
>> > In which case might we be at liberty to specify that on ARM+Device Tree
>> > systems (i.e. those where the f/w tables don't give an enumeration)
>> > there is a 1:1 ma
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 5651110..c10fd2f 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
Need a new LIBXL_HAVE here. Perhaps combined into an umbrella one
On 02/23/2015 04:57 AM, Jan Beulich wrote:
On 21.02.15 at 19:14, wrote:
Use u8-sized node IDs and unsigned PXMs consistently throughout
code (and introduce nodeid_t type).
Signed-off-by: Boris Ostrovsky
I think the description should call out areas not covered, like the
node encoding in the
On Thu, 2015-01-29 at 13:51 +, Julien Grall wrote:
> On 29/01/15 12:31, Stefano Stabellini wrote:
> > On Thu, 29 Jan 2015, Julien Grall wrote:
> >> Hi Stefano,
> >>
> >> On 29/01/15 11:12, Stefano Stabellini wrote:
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> >>
On Thu, 2015-01-29 at 13:48 +, Julien Grall wrote:
> On 29/01/15 12:28, Stefano Stabellini wrote:
> > On Thu, 29 Jan 2015, Julien Grall wrote:
> >> On 29/01/15 11:07, Stefano Stabellini wrote:
> >>> On Tue, 13 Jan 2015, Julien Grall wrote:
> The partial device tree may contains phandle. Th
On Mon, 2015-02-23 at 14:07 +, Jan Beulich wrote:
> >>> On 23.02.15 at 13:45, wrote:
> > On Mon, 2015-02-23 at 08:43 +, Jan Beulich wrote:
> >> >>> On 20.02.15 at 18:33, wrote:
> >> > On Fri, 2015-02-20 at 15:15 +, Jan Beulich wrote:
> >> >> > That's the issue we are trying to resolve
>>> On 23.02.15 at 13:45, wrote:
> On Mon, 2015-02-23 at 08:43 +, Jan Beulich wrote:
>> >>> On 20.02.15 at 18:33, wrote:
>> > On Fri, 2015-02-20 at 15:15 +, Jan Beulich wrote:
>> >> > That's the issue we are trying to resolve, with device tree there is no
>> >> > explicit segment ID, so w
>>> On 23.02.15 at 13:01, wrote:
> On 23/02/15 11:06, Jan Beulich wrote:
>> I have no idea how I came to use __cpumask_set_cpu() there, the
>> conversion should have been set_bit() -> __set_bit(). The wrong
>> construct results in problems on systems with relatively few CPUs.
>>
>> Reported-by: Sa
On 23/02/15 13:47, Jan Beulich wrote:
> While converting to __cpumask_set_cpu() was correct, the first argument
> passed should have been corrected to be "cpu" instead of "nr" at once.
> The wrong construct results in problems on systems with relatively few
> CPUs.
>
> Reported-by: Sander Eikelenbo
While converting to __cpumask_set_cpu() was correct, the first argument
passed should have been corrected to be "cpu" instead of "nr" at once.
The wrong construct results in problems on systems with relatively few
CPUs.
Reported-by: Sander Eikelenboom
Signed-off-by: Jan Beulich
---
v2: As Andrew
flight 35192 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35192/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 3 host-install(3) broken REGR. vs. 34580
test-amd64-amd64-libvirt
On Thu, Feb 19, 2015 at 7:33 PM, Julien Grall wrote:
> On 19/02/15 07:17, vijay.kil...@gmail.com wrote:
>> From: Vijaya Kumar K
>>
>> For arm memory for 1024 irq descriptors are allocated
>> statically irrespective of number of interrupt supported
>> by the platform.
>>
>> With this patch, irq de
On Mon, 2015-02-23 at 10:52 +, Julien Grall wrote:
>
> On 23/02/2015 10:42, Ian Campbell wrote:
> >> On a side note, we consider this platform deprecated we should either
> >> drop the code from Xen or write on the wiki that we don't fully support
> >> it anymore.
> >
> > It's all about degree
On Mon, 2015-02-23 at 08:43 +, Jan Beulich wrote:
> >>> On 20.02.15 at 18:33, wrote:
> > On Fri, 2015-02-20 at 15:15 +, Jan Beulich wrote:
> >> > That's the issue we are trying to resolve, with device tree there is no
> >> > explicit segment ID, so we have an essentially unindexed set of P
Ian Jackson writes ("Re: [PATCH v3 21/24] tools/(lib)xl: Add partial device
tree support for ARM"):
> Is this facility supposed to take untrusted or partially-trusted
> partial device trees ?
Also, is libfdt intended (and safe) for use with untrusted fdt blobs ?
Ian.
___
xen.org writes ("[xen-unstable test] 34925: regressions - trouble:
broken/fail/pass"):
> flight 34925 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/34925/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
flight 34925 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34925/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumpuserxen-amd64 5 xen-bootfail REGR. vs. 34629
test-amd64-amd64-xl-
Julien Grall writes ("[PATCH v3 21/24] tools/(lib)xl: Add partial device tree
support for ARM"):
> Let the user to pass additional nodes to the guest device tree. For this
> purpose, everything in the node /passthrough from the partial device tree \
will
> be copied into the guest device tree.
Pl
On 23/02/15 11:06, Jan Beulich wrote:
> I have no idea how I came to use __cpumask_set_cpu() there, the
> conversion should have been set_bit() -> __set_bit(). The wrong
> construct results in problems on systems with relatively few CPUs.
>
> Reported-by: Sander Eikelenboom
> Signed-off-by: Jan Be
On 23/02/15 4:44 pm, Julien Grall wrote:
On 23/02/2015 10:59, Manish Jaggi wrote:
On 20/02/15 8:09 pm, Ian Campbell wrote:
On Fri, 2015-02-20 at 19:44 +0530, Manish Jaggi wrote:
Another option might be a new hypercall (assuming one doesn't already
exist) to register a PCI bus which would t
1 - 100 of 139 matches
Mail list logo
