> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Wednesday, January 28, 2015 11:25 PM
> To: Olaf Hering
> Cc: xen-devel@lists.xen.org; Xu, Quan
> Subject: Re: [Xen-devel] stubdom vtpm build failure in staging
>
> On Wed, 2015-01-28 at 16:08 +0100, Olaf H
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
include/linux/mm.h between commit 667a0a06c99d ("mm: provide a
find_special_page vma operation") from the xen-tip tree and commit
cfd00f5aa195 ("mm: drop vm_ops->remap_pages and
generic_file_remap_pages() stub") from th
On Wed, Jan 28, 2015 at 03:42:34PM +, Jan Beulich wrote:
> >>> On 28.01.15 at 09:04, wrote:
> > +else
> > +{
> > +unsigned long irqflags;
>
> Some gcc versions can't figure out that this variable doesn't get used
> uninitialized, and hence warn about it
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Tuesday, January 27, 2015 7:01 PM
> To: Hu, Robert
> Cc: Wei Liu; Pang, LongtaoX; xen-devel@lists.xen.org;
> ian.jack...@eu.citrix.com; Zheng, Di
> Subject: Re: [OSSTEST PATCH 2/4] Build XEN and HVM Dom0 kern
Sometimes, a pci bridge device BAR was not assigned
properly. After we call pci_bus_assign_resources(), the
resource of the BAR would be reseted. So if we try to
enable msix for this device, it will map a invalid
resource as the msix base address, and a warning call trace
will report.
pci_bus_assi
flight 33866 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33866/
Perfect :-)
All tests in this flight passed
version targeted for testing:
rumpuserxen 30d72f3fc5e35cd53afd82c8179cc0e0b11146ad
baseline version:
rumpuserxen a14a97d4d127b3a50d01e0171df3
>>> On 1/28/2015 at 11:51 PM, in message <1422460263.5187.27.ca...@citrix.com>,
>>> Ian
Campbell wrote:
> On Mon, 2015-01-19 at 16:28 +0800, Chunyan Liu wrote:
> > This patch series is based on Simon's work. Since there is no progress
> > after last August, I hope we can make this work proce
On Wed, Jan 28, 2015 at 09:39:24AM +0100, Borislav Petkov wrote:
> On Wed, Jan 28, 2015 at 12:10:43AM +, Andrew Cooper wrote:
> > There was a thread on xen-devel but I cant currently find it in the
> > archives.
> >
> > To the best of my memory, it was a 4 core APU system where the BIOS had
>
>>> On 1/28/2015 at 11:54 PM, in message <1422460493.5187.28.ca...@citrix.com>,
>>> Ian
Campbell wrote:
> On Mon, 2015-01-19 at 16:28 +0800, Chunyan Liu wrote:
> > tools/libxl/libxlu_cfg_y.c | 464 ---
> > tools/libxl/libxlu_cfg_y.h | 38 +-
>
> I think these are spurio
>>
>> Right, I think it does.
>>
>> One question: do we need to check flags for IORESOURCE_DISABLED as well?
>> Currently IORESOURCE_DISABLED and IORESOURCE_UNSET are set together for PCI
>> so it probably doesn't matter right now but if this changes we won't want to
>> use BAR that's disabled, wil
flight 33842 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33842/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 11 guest-localmigrate fail REGR. vs. 33488
test-amd64
On 2015/1/28 19:12, Wei Liu wrote:
On Wed, Jan 28, 2015 at 08:42:56AM +0800, Chen, Tiejun wrote:
On 2015/1/27 22:40, Ian Jackson wrote:
Chen, Tiejun writes ("Re: [Qemu-devel] [RFC][PATCH 1/1] libxl: add one machine
property to support IGD GFX passthrough"):
On 2015/1/23 8:43, Chen, Tiejun wro
On 01/28/15 17:47, Don Slutz wrote:
> On 01/28/15 03:19, Jan Beulich wrote:
> On 27.01.15 at 08:58, wrote:
>> On 26.01.15 at 21:19, wrote:
On 01/26/15 11:46, Jan Beulich wrote:
> The delay is not in coding up this, but is that QEMU master (and now
> xenbits's qemu staging) do not
On 01/28/15 04:22, Paul Durrant wrote:
>> -Original Message-
>> From: Wei Liu [mailto:wei.l...@citrix.com]
>> Sent: 27 January 2015 19:06
>> To: xen-devel@lists.xen.org
>> Cc: Wei Liu; Jan Beulich; Paul Durrant; Andrew Cooper
>> Subject: [PATCH] ioreq-server: handle IOREQ_TYPE_PCI_CONFIG in
On Wednesday, January 28, 2015 01:05:25 PM Ian Campbell wrote:
> On Wed, 2015-01-21 at 22:22 -0700, Mike Latimer wrote:
>
> Sorry for the delay.
No problem! Thanks for the comments.
> > @@ -2228,7 +2230,13 @@ static int freemem(uint32_t domid,
> > libxl_domain_build_info *b_info)>
> >
On 01/28/2015 05:41 PM, Andrew Cooper wrote:
On 28/01/2015 22:33, Boris Ostrovsky wrote:
On 01/28/2015 04:49 PM, Andrew Cooper wrote:
On 28/01/2015 19:56, Boris Ostrovsky wrote:
NMI watchdog sets APIC_LVTPC register to generate an NMI when PMU
counter
overflow occurs. This may be overwritten b
On Wed, Jan 28, 2015 at 04:46:05PM +, Ian Campbell wrote:
> On Fri, 2015-01-23 at 11:13 +, Wei Liu wrote:
> > This patch includes configuration options parser and documentation.
> >
> > Please find the hunk to xl.cfg.pod.5 for more information.
> >
> > Signed-off-by: Wei Liu
> > Cc: Ian
On 01/28/15 03:19, Jan Beulich wrote:
On 27.01.15 at 08:58, wrote:
> On 26.01.15 at 21:19, wrote:
>>> On 01/26/15 11:46, Jan Beulich wrote:
As stated before - if feasible, 8 would seem the best option. The
second best one would be to support all four I/O insns (assuming
VM
On 28/01/2015 22:33, Boris Ostrovsky wrote:
> On 01/28/2015 04:49 PM, Andrew Cooper wrote:
>> On 28/01/2015 19:56, Boris Ostrovsky wrote:
>>> NMI watchdog sets APIC_LVTPC register to generate an NMI when PMU
>>> counter
>>> overflow occurs. This may be overwritten by VPMU code later,
>>> effectivel
On 01/28/2015 04:49 PM, Andrew Cooper wrote:
On 28/01/2015 19:56, Boris Ostrovsky wrote:
NMI watchdog sets APIC_LVTPC register to generate an NMI when PMU counter
overflow occurs. This may be overwritten by VPMU code later, effectively
turning off the watchdog.
We should disable VPMU when NMI w
On Wed, Jan 28, 2015 at 04:36:56PM +, Ian Campbell wrote:
> On Fri, 2015-01-23 at 11:13 +, Wei Liu wrote:
> > The algorithm is more or less the same as the one used for PV guest.
>
> Any reason the code can't be shared then? :-D
Because the details are quite different. HVM path is entangl
On Wed, Jan 28, 2015 at 04:41:05PM +, Ian Campbell wrote:
> On Fri, 2015-01-23 at 11:13 +, Wei Liu wrote:
> > +if (info->num_vnuma_nodes != 0) {
> > +int i;
> > +
> > +args.nr_vnuma_info = info->num_vnuma_nodes;
> > +args.vnuma_info = libxl__malloc(gc, sizeof(*ar
On Wed, Jan 28, 2015 at 04:41:11PM +, Ian Campbell wrote:
> On Fri, 2015-01-23 at 11:13 +, Wei Liu wrote:
> > Disallow memory relocation when vNUMA is enabled, because relocated
> > memory ends up off node. Further more, even if we dynamically expand
> > node coverage in hvmloader, low memo
3.13.11-ckt15 -stable review patch. If anyone has any objections, please let
me know.
--
From: Zoltan Kiss
commit 97a6d1bb2b658ac85ed88205ccd1ab809899884d upstream.
There is a long known problem with the netfront/netback interface: if the guest
tries to send a packet which co
On Wed, Jan 28, 2015 at 3:05 PM, Boris Ostrovsky
wrote:
> On 01/28/2015 01:13 PM, Bjorn Helgaas wrote:
>>
>>
>> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
>> index fd60806..c3e7dfc 100644
>> --- a/drivers/pci/msi.c
>> +++ b/drivers/pci/msi.c
>> @@ -694,11 +694,16 @@ static void __iomem *ms
On Wed, Jan 28, 2015 at 04:27:29PM +, Ian Campbell wrote:
> On Fri, 2015-01-23 at 11:13 +, Wei Liu wrote:
> > +/* Generate one vmemrange for each virtual node. */
> > +next = 0;
> > +for (i = 0; i < b_info->num_vnuma_nodes; i++) {
> > +libxl_vnode_info *p = &b_info->vnum
On Wed, Jan 28, 2015 at 04:04:12PM +, Ian Campbell wrote:
> On Fri, 2015-01-23 at 11:13 +, Wei Liu wrote:
> > A domain can contain several virtual NUMA nodes, hence we introduce an
> > array in libxl_domain_build_info.
> >
> > libxl_vnode_info contains the size of memory in that node, the
On Wed, Jan 28, 2015 at 04:13:28PM +, Ian Campbell wrote:
> On Fri, 2015-01-23 at 11:13 +, Wei Liu wrote:
> > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> > index 6d3ac58..39356ba 100644
> > --- a/tools/libxl/libxl_internal.h
> > +++ b/tools/libxl/libxl_interna
On 28/01/2015 19:56, Boris Ostrovsky wrote:
> NMI watchdog sets APIC_LVTPC register to generate an NMI when PMU counter
> overflow occurs. This may be overwritten by VPMU code later, effectively
> turning off the watchdog.
>
> We should disable VPMU when NMI watchdog is running.
>
> Signed-off-by:
On 01/28/2015 01:13 PM, Bjorn Helgaas wrote:
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index fd60806..c3e7dfc 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -694,11 +694,16 @@ static void __iomem *msix_map_region(struct pci_dev *dev,
unsigned nr_entries)
{
resource
> -Original Message-
> From: win-pv-devel-boun...@lists.xenproject.org [mailto:win-pv-devel-
> boun...@lists.xenproject.org] On Behalf Of Christian Refvik
> Sent: 27 January 2015 03:02
> To: win-pv-de...@lists.xenproject.org
> Cc: xen-de...@lists.xenproject.org
> Subject: [win-pv-devel] Por
Don't have the hypervisor update APIC_LVTPC when _it_ thinks the vector
should be updated. Instead, handle guest's APIC_LVTPC accesses and write what
the guest explicitly wanted (but only when VPMU is enabled).
This is updated version of commit 8097616fbdda that was reverted by
cc3404093c85. Unlik
The first patch is to disable VPMU when watchdog is on since both are using
APIC_LVTPC register and VPMU, when running, will overwrite watchdog's settings.
The second patch is update to the earlier (reverted) commit 8097616. We prevent
guests's updates to APIC_LVTPC when VPMU is disabled. Without
NMI watchdog sets APIC_LVTPC register to generate an NMI when PMU counter
overflow occurs. This may be overwritten by VPMU code later, effectively
turning off the watchdog.
We should disable VPMU when NMI watchdog is running.
Signed-off-by: Boris Ostrovsky
---
xen/arch/x86/hvm/vpmu.c|
...
> (Looking at the surrounding code I'm also puzzled by all the
> pci_write?()-s in that bus scanning loop: Most if not all of them
> should be done by the BIOS, not hvmloader. But of course that's
> the case for the BAR setup further down too.)
>
I do not know the history, but seabios (which
flight 33840 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33840/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumpuserxen-amd64 8 guest-start fail REGR. vs. 33815
test-amd64-i386-xl
Hi Stefano,
On 28/01/15 18:52, Stefano Stabellini wrote:
> On Tue, 13 Jan 2015, Julien Grall wrote:
>> The physdev sub-hypercalls PHYSDEVOP_{,map}_pirq allow the toolstack to
>> assign/deassign a physical IRQ to the guest (via the config options "irqs"
>> for xl). The x86 version is using them wit
On Tue, 13 Jan 2015, Julien Grall wrote:
> The toolstack may not have deassign every device used by a guest.
> Therefore we have to go through the device list and removing them before
> asking the IOMMU drivers to release memory for this domain.
>
> This can be done by moving the call to the relea
Hi Stefano,
On 28/01/15 18:26, Stefano Stabellini wrote:
> On Tue, 13 Jan 2015, Julien Grall wrote:
>> Each domain may have a different number of IRQs depending on the devices
>> assigned to it.
>>
>> Rather re-using the number of IRQs used by the hardwared GIC, let the
>> toolstack specify the nu
On Tue, 13 Jan 2015, Julien Grall wrote:
> The physdev sub-hypercalls PHYSDEVOP_{,map}_pirq allow the toolstack to
> assign/deassign a physical IRQ to the guest (via the config options "irqs"
> for xl). The x86 version is using them with PIRQ (IRQ bound to an event
> channel). As ARM doesn't have a
On Tue, 13 Jan 2015, Julien Grall wrote:
> Xen has to release IRQ routed to a domain in order to reuse later. Currently
> only SPIs can be routed to the guest so we only need to browse SPIs for a
> specific domain.
>
> Futhermore, a guest can crash and let the IRQ in an incorrect state (i.e has
>
On Tue, 13 Jan 2015, Julien Grall wrote:
> Each domain may have a different number of IRQs depending on the devices
> assigned to it.
>
> Rather re-using the number of IRQs used by the hardwared GIC, let the
> toolstack specify the number of SPIs when the domain is created. This
> will avoid to wa
On Tue, 13 Jan 2015, Julien Grall wrote:
> With the addition of interrupt assignment to guest, we need to make sure
> the guest don't blow up the interrupt management in Xen.
>
> Before associating the IRQ to a vIRQ we need to make sure:
> - the vIRQ is not already associated to another IRQ
>
[+cc Konrad, Boris, David, xen-devel, Alex, kvm]
On Wed, Jan 28, 2015 at 09:52:17AM +0800, Yijing Wang wrote:
> Sometimes, a pci bridge device BAR was not assigned
> properly. After we call pci_bus_assign_resources(), the
> resource of the BAR would be reseted. So if we try to
> enable msix for th
On 28/01/15 17:55, Stefano Stabellini wrote:
>> ---
>> xen/arch/arm/irq.c| 58
>> +++
>> xen/include/asm-arm/irq.h | 2 ++
>> 2 files changed, 56 insertions(+), 4 deletions(-)
>>
>> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
>> index
The static error_str[] buffer is not thread-safe, and 1024 bytes is
unreasonably large. Reduce to 256 bytes (which is still much larger than any
current use), and move it to being a stack variable.
Also, propagate the Noreturn attribute from caml_raise_with_string().
Signed-off-by: Andrew Cooper
On Tue, 13 Jan 2015, Julien Grall wrote:
> Currently Xen only supports SPIs routing for guest, add a function
> is_assignable_irq to check if we can assign a given IRQ to the guest.
>
> Secondly, make sure the vIRQ is not the greater that the number of IRQs handle
> to the vGIC and it's an SPIs.
>
On 28/01/15 17:06, David Vrabel wrote:
> On 28/01/15 16:45, Julien Grall wrote:
>> On 27/01/15 16:53, Wei Liu wrote:
>>> On Tue, Jan 27, 2015 at 04:47:45PM +, Julien Grall wrote:
On 27/01/15 16:45, Wei Liu wrote:
> On Tue, Jan 27, 2015 at 04:03:52PM +, Julien Grall wrote:
>> Hi
On Wed, Jan 28, 2015 at 04:56:02PM +, Jan Beulich wrote:
> >>> On 28.01.15 at 17:17, wrote:
> > On Wed, Jan 28, 2015 at 11:03:19AM -0500, Konrad Rzeszutek Wilk wrote:
> >> I am not really sure of what the work-around should be in Xen except
> >> making SetVirtualAddressMap work..
> >
> > Hmmm
On 28/01/15 16:45, Julien Grall wrote:
> On 27/01/15 16:53, Wei Liu wrote:
>> On Tue, Jan 27, 2015 at 04:47:45PM +, Julien Grall wrote:
>>> On 27/01/15 16:45, Wei Liu wrote:
On Tue, Jan 27, 2015 at 04:03:52PM +, Julien Grall wrote:
> Hi,
>
> While I'm working on support for
Euan Harris writes ("Re: Cancelling asynchronous operations in libxl"):
> On Tue, Jan 20, 2015 at 04:38:24PM +, Ian Jackson wrote:
> > * Is an API along these lines going to meet your needs ?
>
> The API you propose for libxl_ao_cancel, as described in the comment in
> libxl.h, looks reasonab
On 28/01/15 16:56, Julien Grall wrote:
> On 28/01/15 16:47, Stefano Stabellini wrote:
>>> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
>>> index 25ecf1d..830832c 100644
>>> --- a/xen/arch/arm/irq.c
>>> +++ b/xen/arch/arm/irq.c
>>> @@ -31,6 +31,13 @@
>>> static unsigned int local_irqs_type[
On 28 January 2015 at 15:28, Olivier Martin wrote:
> Reviewed-By: Olivier Martin
>
Looking at these patches again, it might make sense to replace #9, #10
and #11 with a single patch that introduces RelocatablePrePi under
ArmVirtualizationPkg with these changes already applied. That way, we
adher
On 28/01/15 16:47, Stefano Stabellini wrote:
>> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
>> index 25ecf1d..830832c 100644
>> --- a/xen/arch/arm/irq.c
>> +++ b/xen/arch/arm/irq.c
>> @@ -31,6 +31,13 @@
>> static unsigned int local_irqs_type[NR_LOCAL_IRQS];
>> static DEFINE_SPINLOCK(loca
>>> On 28.01.15 at 17:17, wrote:
> On Wed, Jan 28, 2015 at 11:03:19AM -0500, Konrad Rzeszutek Wilk wrote:
>> I am not really sure of what the work-around should be in Xen except
>> making SetVirtualAddressMap work..
>
> Hmmm... Crazy idea. IIRC, we use RS in 1:1 mapping. If we need to call
> SetV
On 28/01/15 16:36, Stefano Stabellini wrote:
> On Tue, 13 Jan 2015, Julien Grall wrote:
>> When a device is marked for passthrough (via the new property
>> "xen,passthrough"),
>> dom0 must not access to the device (i.e not loading a driver), but should
>> be able to manage the MMIO/interrupt of th
On Tue, 13 Jan 2015, Julien Grall wrote:
> When a device is marked for passthrough (via the new property
> "xen,passthrough"),
> dom0 must not access to the device (i.e not loading a driver), but should
> be able to manage the MMIO/interrupt of the passthrough device.
>
> The latter part will all
On Tue, 13 Jan 2015, Julien Grall wrote:
> Actually Xen is assuming that the virtual IRQ will always be the same as IRQ.
>
> Modify route_guest_irq to take the virtual IRQ in parameter and let Xen
> assign a different IRQ number. Also store the vIRQ in the desc action to
> easily retrieve easily t
On 27/01/15 16:53, Wei Liu wrote:
> On Tue, Jan 27, 2015 at 04:47:45PM +, Julien Grall wrote:
>> On 27/01/15 16:45, Wei Liu wrote:
>>> On Tue, Jan 27, 2015 at 04:03:52PM +, Julien Grall wrote:
Hi,
While I'm working on support for 64K page in netfront, I got
an rcu_sced s
On Fri, 2015-01-23 at 11:13 +, Wei Liu wrote:
> This patch includes configuration options parser and documentation.
>
> Please find the hunk to xl.cfg.pod.5 for more information.
>
> Signed-off-by: Wei Liu
> Cc: Ian Campbell
> Cc: Ian Jackson
> Cc: Dario Faggioli
> Cc: Elena Ufimtseva
>
On Fri, 2015-01-23 at 11:13 +, Wei Liu wrote:
> This patches does following things:
I'm leaving this one to Ian J.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Fri, 2015-01-23 at 11:13 +, Wei Liu wrote:
> Disallow memory relocation when vNUMA is enabled, because relocated
> memory ends up off node. Further more, even if we dynamically expand
> node coverage in hvmloader, low memory and high memory may reside
> in different physical nodes, blindly r
On Fri, 2015-01-23 at 11:13 +, Wei Liu wrote:
> +if (info->num_vnuma_nodes != 0) {
> +int i;
> +
> +args.nr_vnuma_info = info->num_vnuma_nodes;
> +args.vnuma_info = libxl__malloc(gc, sizeof(*args.vnuma_info) *
> +args.nr_vnuma_
On Fri, 2015-01-23 at 11:13 +, Wei Liu wrote:
> The algorithm is more or less the same as the one used for PV guest.
Any reason the code can't be shared then? :-D
>
> +if ( nr_pages > target_pages )
> +memflags |= XENMEMF_populate_on_demand;
OOI how does vNUMA and PoD interact?
On Fri, 2015-01-23 at 11:13 +, Wei Liu wrote:
> Move a while loop in xc_hvm_build_x86 one block to the right. No
> functional change introduced.
>
> Functional changes will be introduced in next patch.
>
> Signed-off-by: Wei Liu
Acked-by: Ian Campbell
___
On Fri, 2015-01-23 at 11:13 +, Wei Liu wrote:
> Transform the user supplied vNUMA configuration into libxl internal
> representations, and finally libxc representations. Check validity of
> the configuration along the line.
>
> Signed-off-by: Wei Liu
Acked-by: Ian Campbell
__
On Fri, 2015-01-23 at 11:13 +, Wei Liu wrote:
> +/* Generate one vmemrange for each virtual node. */
> +next = 0;
> +for (i = 0; i < b_info->num_vnuma_nodes; i++) {
> +libxl_vnode_info *p = &b_info->vnuma_nodes[i];
> +
> +GCREALLOC_ARRAY(v, i+1);
Can we not just all
Hi Stefano,
On 28/01/15 16:18, Stefano Stabellini wrote:
> On Tue, 13 Jan 2015, Julien Grall wrote:
>> The check to avoid mapping disabled device in DOM0 was added in the
>> anticipation
>> of the device passthrough. But, a brand new property will be added later to
>> mark
>> device which will p
On Tue, 13 Jan 2015, Julien Grall wrote:
> Xen is only able to handle one GIC controller. Some platform may contain
> other interrupt controller.
>
> Make sure to only translate IRQ mapped into the GIC handled by Xen.
>
> Signed-off-by: Julien Grall
>
Acked-by: Stefano Stabellini
>
> Ch
On Tue, 13 Jan 2015, Julien Grall wrote:
> The check to avoid mapping disabled device in DOM0 was added in the
> anticipation
> of the device passthrough. But, a brand new property will be added later to
> mark
> device which will passthrough. At the same time, remove the memory type
> check beca
On Wed, Jan 28, 2015 at 11:03:19AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 28, 2015 at 08:40:44AM +, Jan Beulich wrote:
> > >>> On 27.01.15 at 19:20, wrote:
> > > On Tue, Jan 27, 2015 at 04:17:05PM +, Jan Beulich wrote:
> > >> Again - apart from mapping the range, did you also ma
On 28 January 2015 at 15:13, Olivier Martin wrote:
> Same question as last time, would it not be better to have a PCD instead of
> hardcoded value?
Ah yes, I remember reading that but failed to take it into account.
> Some platforms might want to have a larger FDT padding.
>
Agreed. Will add it
On Tue, 13 Jan 2015, Julien Grall wrote:
> Currently the function to translate IRQ from the device tree is set
> unconditionally to be able to be able to retrieve serial/timer IRQ before the
> GIC has been initialized.
>
> It assumes that the xlate function won't never changed. We may also need t
On Wed, Jan 28, 2015 at 11:03:19AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 28, 2015 at 08:40:44AM +, Jan Beulich wrote:
> > >>> On 27.01.15 at 19:20, wrote:
> > > On Tue, Jan 27, 2015 at 04:17:05PM +, Jan Beulich wrote:
> > >> Again - apart from mapping the range, did you also ma
On Wed, 2015-01-28 at 18:07 +0200, Pasi Kärkkäinen wrote:
> On Wed, Jan 28, 2015 at 03:51:03PM +, Ian Campbell wrote:
> > Although this is PV USB only I think the intention was to leave a
> > suitable hole for HVM emulated USB support. Or am I mis-remembering?
> >
>
> PVUSB should work with
Hello Ian,
When I discussed with Iurii Konovalenko about this naming during
review I mentioned following the Linux kernel way.
Shmobile within kernel is arm specific, not the same as arch/sh. In
the kernel you would find arch/arm/mach-shmobile folder where
Renesas'es R-CarX SoCs support reside. F
Hi,
On Tue, Jan 20, 2015 at 04:38:24PM +, Ian Jackson wrote:
> * Is an API along these lines going to meet your needs ?
The API you propose for libxl_ao_cancel, as described in the comment in
libxl.h, looks reasonable to us.The comment for ERROR_NOTIMPLEMENTED
is a bit confusing: under w
On Fri, 2015-01-23 at 11:13 +, Wei Liu wrote:
> This function gets the machine E820 map and sanitize it according to PV
> guest configuration.
>
> This will be used in later patch. No functional change introduced in
> this patch.
>
> Signed-off-by: Wei Liu
Acked-by: Ian Campbell
___
On Fri, 2015-01-23 at 11:13 +, Wei Liu wrote:
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 6d3ac58..39356ba 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -3394,6 +3394,11 @@ void libxl__numa_candidate_put_nodemap(libx
On Tue, 13 Jan 2015, 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
> and can never change.
>
> For now only the gic_version is set. In long run, there will be mo
On Wed, Jan 28, 2015 at 03:51:03PM +, Ian Campbell wrote:
> On Mon, 2015-01-19 at 16:28 +0800, Chunyan Liu wrote:
> > This patch series is based on Simon's work. Since there is no progress
> > after last August, I hope we can make this work proceed. Any comment will
> > be very appreciated.
> >
On Fri, 2015-01-23 at 11:13 +, Wei Liu wrote:
> A vnode consists of one or more vmemranges (virtual memory range). One
> example of multiple vmemranges is that there is a hole in one vnode.
>
> Currently we haven't exported vmemrange interface to libxl user.
> Vmemranges are generated during
On Fri, 2015-01-23 at 11:13 +, Wei Liu wrote:
> A domain can contain several virtual NUMA nodes, hence we introduce an
> array in libxl_domain_build_info.
>
> libxl_vnode_info contains the size of memory in that node, the distance
> from that node to every nodes, the underlying pnode and a bit
On 28 January 2015 at 15:04, Olivier Martin wrote:
> I do not have a strong opinion on this patch.
> It would be better to keep the dynamic PCD support in this patch. But I am
> aware it is not possible with PrePi (I had the issue a couple of weeks ago).
> Dynamic Pcds are actually supported when
On Wed, Jan 28, 2015 at 08:40:44AM +, Jan Beulich wrote:
> >>> On 27.01.15 at 19:20, wrote:
> > On Tue, Jan 27, 2015 at 04:17:05PM +, Jan Beulich wrote:
> >> Again - apart from mapping the range, did you also make sure it
> >> didn't get passed to the allocator (and hence couldn't have got
On Fri, 2015-01-23 at 11:13 +, Wei Liu wrote:
> +/* Setup dummy vNUMA information if it's not provided. Note
> + * that this is a valid state if libxl doesn't provide any
> + * vNUMA information.
> + *
> + * The dummy values make libxc allocate all pages
On Mon, 2015-01-19 at 16:28 +0800, Chunyan Liu wrote:
> tools/libxl/libxlu_cfg_y.c | 464 ---
> tools/libxl/libxlu_cfg_y.h | 38 +-
I think these are spurious changes caused by you having different
versions of flex/bison installed, could you arrange to omit these
please.
c/s 5b5c40c0d1 "libxc: introduce a per architecture scratch pfn for temporary
grant mapping" accidentally an issue whereby there were two paths out of
xc_core_arch_get_scratch_gpfn() which returned 0, but only one of which
assigned a value to the gpfn parameter.
xc_domain_maximum_gpfn() can validl
On Mon, 2015-01-19 at 16:28 +0800, Chunyan Liu wrote:
> This patch series is based on Simon's work. Since there is no progress
> after last August, I hope we can make this work proceed. Any comment will
> be very appreciated.
>
> It adds pvusb toolstack implementation, with pvusb kernel side work,
>>> On 28.01.15 at 09:04, wrote:
> +else
> +{
> +unsigned long irqflags;
Some gcc versions can't figure out that this variable doesn't get used
uninitialized, and hence warn about it. I fixed this while committing, at
once changing the name to the more conv
On 28/01/15 15:25, Jan Beulich wrote:
> To make obvious that such statics are safe to use, they should be
> const. In some of the cases, they don't even need to be static.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
>
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm
Reviewed-By: Olivier Martin
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 26 January 2015 19:03
> To: edk2-de...@lists.sourceforge.net; ler...@redhat.com; Olivier
> Martin; roy.fr...@linaro.org; leif.lindh...@linaro.org;
> stefano.stabell...@eu.cit
On Wed, 2015-01-28 at 15:24 +, Jan Beulich wrote:
> "origPtr" is used as an offset into the bd->dbuf[] array. That array is
> allocated in start_bunzip() and has "bd->dbufSize" number of elements so
> the test here should be >= instead of >.
>
> Later we check "origPtr" again before using it
To make obvious that such statics are safe to use, they should be
const. In some of the cases, they don't even need to be static.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -2164,7 +2164,7 @@ int sh_remove_write_access(struct vcpu *
"origPtr" is used as an offset into the bd->dbuf[] array. That array is
allocated in start_bunzip() and has "bd->dbufSize" number of elements so
the test here should be >= instead of >.
Later we check "origPtr" again before using it as an offset so I don't
know if this bug can be triggered in rea
On Wed, 2015-01-28 at 16:08 +0100, Olaf Hering wrote:
> Current staging fails in the install-stubdom target:
>
> ...
> [ 488s] tpm2_types.h:86: error: redefinition of typedef 'BYTE'
> [ 488s] tcg.h:404: error: previous declaration of 'BYTE' was here
> [ 488s] tpm2_types.h:87: error: redefinitio
On Wed, 28 Jan 2015, Ian Campbell wrote:
> On Wed, 2015-01-28 at 14:35 +, Stefano Stabellini wrote:
> > On Wed, 28 Jan 2015, Ian Campbell wrote:
> > > On Mon, 2015-01-26 at 17:03 +, Stefano Stabellini wrote:
> > > > In libxl_set_memory_target when setting the new maxmem, retain the same
> >
Thanks, I will check and fix it tomorrow. It is 23:12 PM Pacific time now.
Thanks
Quan
> -Original Message-
> From: Olaf Hering [mailto:o...@aepfle.de]
> Sent: Wednesday, January 28, 2015 11:09 PM
> To: xen-devel@lists.xen.org
> Cc: Xu, Quan
> Subject: stubdom vtpm build failure in stagi
Same question as last time, would it not be better to have a PCD instead of
hardcoded value?
Some platforms might want to have a larger FDT padding.
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 26 January 2015 19:03
> To: edk2-de...@lists.sourcefo
Current staging fails in the install-stubdom target:
...
[ 488s] tpm2_types.h:86: error: redefinition of typedef 'BYTE'
[ 488s] tcg.h:404: error: previous declaration of 'BYTE' was here
[ 488s] tpm2_types.h:87: error: redefinition of typedef 'BOOL'
[ 488s] tcg.h:405: error: previous declarati
1 - 100 of 193 matches
Mail list logo
