>>> On 6/12/2015 at 12:16 AM, in message
<21881.46148.466883.923...@mariner.uk.xensource.com>, Ian Jackson
wrote:
> Chunyan Liu writes ("[Xen-devel] [PATCH V4 2/7] libxl_read_file_contents: add
>
> new entry to read sysfs file"):
> > Sysfs file has size=4096 but actual file content is less
>>> On 11.06.15 at 17:28, wrote:
> At 15:51 +0100 on 05 Jun (1433519478), Jan Beulich wrote:
>> Iirc before both of these changes, and the v10 ones imo should
>> have invalidated it. Tim, I'm particularly trying to understand
>> whether you're okay with the original's (potentially even heavier)
>>
On 2015/6/11 17:38, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Thursday, June 11, 2015 9:15 AM
Now we get this map layout by call XENMEM_memory_map then
save them into one global variable memory_map[]. It should
include lowmem range, rdm range and highmem range. Note
rdm range and highmem range
On 06/10/2015 05:20 AM, Chunyan Liu wrote:
Add pvusb commands: usb-ctrl-attach, usb-ctrl-detach, usb-list,
usb-attach and usb-detach.
To attach a usb device to guest through pvusb, one could follow
following example:
#xl usb-ctrl-attach test_vm version=1 num_ports=8
#xl usb-list test_vm
>>> On 6/12/2015 at 12:42 AM, in message
<21881.47707.526863.158...@mariner.uk.xensource.com>, Ian Jackson
wrote:
> Chunyan Liu writes ("[Xen-devel] [PATCH V4 3/7] libxl: add pvusb API"):
> > Add pvusb APIs, including:
> ...
>
> Thanks for your contribution. I'm afraid I haven't had time
> -Original Message-
> From: Wen Congyang [mailto:we...@cn.fujitsu.com]
> Sent: 12 June 2015 04:22
> To: Paul Durrant; Yang Hongyang; Andrew Cooper; xen-devel@lists.xen.org
> Cc: Wei Liu; Ian Campbell; guijianf...@cn.fujitsu.com;
> yunhong.ji...@intel.com; Eddie Dong; rshri...@cs.ubc.ca; Ia
On 2015/6/11 17:51, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Thursday, June 11, 2015 9:15 AM
When allocating mmio address for PCI bars, we need to make
sure they don't overlap with reserved regions.
Signed-off-by: Tiejun Chen
---
tools/firmware/hvmloader/pci.c | 36
+++
>>> On 12.06.15 at 01:23, wrote:
> There are two usages on MTRRs:
> 1) MTRR entries set by firmware
> 2) MTRR entries set by OS drivers
>
> We can obsolete 2), but we have no control over 1). As UEFI firmwares
> also set this up, this usage will continue to stay. So, we should not
> get rid o
>>> On 6/12/2015 at 03:37 PM, in message <557a8c57.1040...@suse.com>, Juergen
>>> Gross
wrote:
> On 06/10/2015 05:20 AM, Chunyan Liu wrote:
> > Add pvusb commands: usb-ctrl-attach, usb-ctrl-detach, usb-list,
> > usb-attach and usb-detach.
> >
> > To attach a usb device to guest through pvu
>>> On 12.06.15 at 04:10, wrote:
> On 2015/6/11 20:52, Tim Deegan wrote:
>> which would be better handeld explicitly:
>>
>> if ( p2mt == p2m_invalid || p2mt == p2m_mmio_dm )
>> ...
>>
>
> So if I'm correct, we should do this check explicitly,
>
> if ( p2mt == p2m_inva
>>> On 6/12/2015 at 03:39 PM, in message
<557afd2f0266000d4...@relay2.provo.novell.com>, "Chun Yan Liu"
wrote:
>
On 6/12/2015 at 12:42 AM, in message
> <21881.47707.526863.158...@mariner.uk.xensource.com>, Ian Jackson
> wrote:
> > Chunyan Liu writes ("[Xen-devel] [PATCH V4 3/7]
On 2015/6/11 17:59, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Thursday, June 11, 2015 9:15 AM
Now we can use that memory map to build our final
e820 table but it may need to reorder all e820
entries.
Signed-off-by: Tiejun Chen
---
tools/firmware/hvmloader/e820.c | 62
++
On 2015/6/12 16:04, Jan Beulich wrote:
On 12.06.15 at 04:10, wrote:
On 2015/6/11 20:52, Tim Deegan wrote:
which would be better handeld explicitly:
if ( p2mt == p2m_invalid || p2mt == p2m_mmio_dm )
...
So if I'm correct, we should do this check explicitly,
i
On 06/12/2015 10:03 AM, Chun Yan Liu wrote:
On 6/12/2015 at 03:37 PM, in message <557a8c57.1040...@suse.com>, Juergen Gross
wrote:
On 06/10/2015 05:20 AM, Chunyan Liu wrote:
...
+} else if (MATCH_OPTION("ports", argv[optind], oparg)) {
+usbctrl.ports = atoi(oparg);
On 2015/6/11 18:02, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Thursday, June 11, 2015 9:15 AM
This patch passes rdm reservation policy to xc_assign_device() so the policy
is checked when assigning devices to a VM.
Signed-off-by: Tiejun Chen
---
tools/libxc/include/xenctrl.h | 3 ++-
On 2015/6/11 18:19, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Thursday, June 11, 2015 9:15 AM
While building a VM, HVM domain builder provides struct hvm_info_table{}
to help hvmloader. Currently it includes two fields to construct guest
e820 table by hvmloader, low_mem_pgend and high_mem_pgen
From: Chen Baozi
Currently the number of vcpus on arm64 with GICv3 is limited up to 8 due
to the fixed size of redistributor mmio region. Increasing the size
makes the number expand to 16 because of AFF0 restriction on GICv3.
To create a guest up to 128 vCPUs, which is the maxium number that GIC-
From: Chen Baozi
Currently it only supports up to 8 vCPUs. Increase the region to hold
up to 128 vCPUs, which is the maximum number that GIC-500 supports.
Signed-off-by: Chen Baozi
Reviewed-by: Julien Grall
Acked-by: Ian Campbell
---
xen/include/public/arch-arm.h | 4 ++--
1 file changed, 2
On Thu, 2015-06-11 at 14:38 -0700, Manish Jaggi wrote:
>
> On Wednesday 10 June 2015 12:21 PM, Julien Grall wrote:
> > Hi,
> >
> > On 10/06/2015 08:45, Ian Campbell wrote:
> >>> 4. DomU access / assignment PCI device
> >>> --
> >>> When a device is attached to a
From: Chen Baozi
There are 3 places to change:
* Initialise vMPIDR value in vcpu_initialise()
* Find the vCPU from vMPIDR affinity information when accessing GICD
registers in vGIC
* Find the vCPU from vMPIDR affinity information when booting with vPSCI
in vGIC
- Both PSCI 0.1 and PSCI 0.2
From: Chen Baozi
GICv3 restricts that the maximum number of CPUs in affinity 0 (one
cluster) is 16. (See the note of 'Bits[15:0]' in '5.7.29 ICC_SGI0R_EL1
ICC_SGI1R_EL1 and ICC_ASGI1R_EL1, GICv3 Architecture Specification')
That is to say the upper 4 bits of affinity 0 is unused. Current
implemen
From: Chen Baozi
According to ARM CPUs bindings, the reg field should match the MPIDR's
affinity bits. We will use AFF0 and AFF1 when constructing the reg value
of the guest at the moment, for it is enough for the current max vcpu
number.
Signed-off-by: Chen Baozi
Reviewed-by: Julien Grall
Ack
From: Chen Baozi
The old unsigned long type of vcpu_mask can only express 64 cpus at the
most, which might not be enough for the guest which used vGICv3. We
introduce a new struct sgi_target for the target cpu list of SGI, which
holds the affinity path information (only level 1 at the moment). Fo
From: Chen Baozi
Each vGIC driver supports different maximum numbers of vCPU. For
example, GICv2 is limited to 8 vCPUs, while GICv3 can support up
to 4096 vCPUs if we use both AFF0 and AFF1. Thus, domain_max_vcpus
should depend on not only MAX_VIRT_CPUS but also the version
of vGIC that the guest
From: Chen Baozi
According to ARM CPUs bindings, the reg field should match the MPIDR's
affinity bits. We will use AFF0 and AFF1 when constructing the reg value
of the guest at the moment, for it is enough for the current max vcpu
number.
Signed-off-by: Chen Baozi
Acked-by: Ian Campbell
Review
From: Chen Baozi
After we have increased the size of GICR in address space for guest
and made use of both AFF0 and AFF1 in (v)MPIDR, we are now able to
support up to 4096 vCPUs in theory. However, it will cost 512M
address space for GICR region, which is unnecessary big at the
moment. Considering
The interface description of pvUSB lacks some access macros as using
linux kernel macros is assumed to work well. This solution is rather
unfriendly for pvusb implementations being outside the linux kernel.
Additionally things will break quite unpleasent in case the linux
kernel implementation is c
On Thu, 2015-06-11 at 17:57 +0100, Ian Jackson wrote:
> Signed-off-by: Ian Jackson
> CC: Ian Campbell
> CC: Wei Liu
> CC: Juergen Gross
Acked-by: Ian Campbell
AO_INITIATOR_ENTRY was just a stray remainder of some wip name?
> ---
> tools/libxl/libxl_internal.h |5 +++--
> 1 file changed
On Thu, Jun 11, 2015 at 3:10 PM, Ian Campbell wrote:
> Draft F follows. Also at:
> http://xenbits.xen.org/people/ianc/vits/draftF.{pdf,html}
>
> Here's a quick update based on feedback prior to meeting on #xenarm at
> 12:00AM BST / 7:00AM EDT / 4:30PM IST (which is ~1:20 from now)
>
> Ian.
>
> % X
>>> On 12.06.15 at 05:03, wrote:
> On 11/06/2015 22:02, Julien Grall wrote:
>> On 11/06/2015 04:31, Wei Wang wrote:
>> > +else
>> > +{
>> > +list_for_each(pos, &cpufreq_governor_list)
>> > gov_num++;
>>
>> The indentation looks wrong to me.
>
> It has four "+$", should
On Fri, 2015-06-12 at 03:46 +, Pang, LongtaoX wrote:
>
> > -Original Message-
> > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > Sent: Thursday, June 11, 2015 11:15 PM
> > To: Pang, LongtaoX
> > Cc: xen-devel@lists.xen.org; ian.campb...@citrix.com; wei.l...@citrix.com;
> > H
Constructing dom0 may take a few seconds, particularly if the slow VESA
graphics terminal is used. Process pending softirqs a few times to avoid
tripping a watchdog with a short timeout.
Signed-off-by: Ross Lagerwall
---
Changes in v2: Process pending softirqs inside ELF code.
xen/arch/x86/dom
On 2015/6/11 18:25, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Thursday, June 11, 2015 9:15 AM
Currently we're intending to cover this kind of devices
we're -> we're not?
I mean currently we want to handle this shared case *simply* so I think
its still "we're", right?
with shared RMRR
On Fri, 2015-06-12 at 11:42 +0800, Robert Hu wrote:
> Hi Ian J., because nested Xen isn't that matured at present; it is
> currently 'tech preview' phase. We now just add some sanity test case to
> defend current work fruits. We can add more complicated test cases later
> as nested Xen development
>>> On 12.06.15 at 08:31, wrote:
> On 2015/6/11 17:28, Tian, Kevin wrote:
>>> From: Chen, Tiejun
>>> Sent: Thursday, June 11, 2015 9:15 AM
>>> @@ -1940,7 +1942,8 @@ static int intel_iommu_remove_device(u8 devfn, struct
>>> pci_dev
>>> *pdev)
>>>PCI_DEVFN2(bdf) != devfn )
>>>
On 12/06/15 03:30, Luis R. Rodriguez wrote:
> On Fri, Jan 30, 2015 at 1:57 PM, Luis R. Rodriguez wrote:
>> On Fri, Jan 30, 2015 at 08:37:33PM +, Andrew Cooper wrote:
>>> The right thing to do is to fix the hypercall implementation, at which
>>> point the utility below is fine and xc_microcode_
On Fri, 2015-06-12 at 14:07 +0530, Vijay Kilari wrote:
Please could you trim your quotes to only include the bit you are
referring to. Otherwise there is a high chance I will miss a one line
comment in the middle of the thousand lines of quoted matter.
> > The `GITS_BASER0` will be setup to reque
On 2015/6/11 18:22, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Thursday, June 11, 2015 9:15 AM
Before we refine RMRR mechanism, USB RMRR may conflict with guest bios
region so we always ignore USB RMRR.
If USB RMRR conflicts with guest bios, the conflict is always there
before and after your
On Fri, 2015-06-12 at 09:44 +0100, Ian Campbell wrote:
> On Fri, 2015-06-12 at 11:42 +0800, Robert Hu wrote:
> > Hi Ian J., because nested Xen isn't that matured at present; it is
> > currently 'tech preview' phase. We now just add some sanity test case to
> > defend current work fruits. We can add
On Fri, 2015-06-12 at 17:00 +0800, Robert Hu wrote:
> On Fri, 2015-06-12 at 09:44 +0100, Ian Campbell wrote:
> > On Fri, 2015-06-12 at 11:42 +0800, Robert Hu wrote:
> > > Hi Ian J., because nested Xen isn't that matured at present; it is
> > > currently 'tech preview' phase. We now just add some sa
On 2015/6/12 16:45, Jan Beulich wrote:
On 12.06.15 at 08:31, wrote:
On 2015/6/11 17:28, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Thursday, June 11, 2015 9:15 AM
@@ -1940,7 +1942,8 @@ static int intel_iommu_remove_device(u8 devfn, struct
pci_dev
*pdev)
PCI_DEVFN2(bdf) != dev
>>> On 12.06.15 at 11:20, wrote:
> On 2015/6/12 16:45, Jan Beulich wrote:
> On 12.06.15 at 08:31, wrote:
>>> On 2015/6/11 17:28, Tian, Kevin wrote:
> From: Chen, Tiejun
> Sent: Thursday, June 11, 2015 9:15 AM
> @@ -1940,7 +1942,8 @@ static int intel_iommu_remove_device(u8 devfn,
On Wed, 2015-06-10 at 22:50 -0700, Meng Xu wrote:
> Hi Dario,
>
> First I think I got most of the points you raised/explained! They are
> very very clear and thanks for the detailed explanation of your idea!
>
Glad you got it and (sort of :-) ) agree.
> >> 2015-06-09 5:53 GMT-07:00 Dario Faggiol
Ian, Jan,
you seem to be disagreeing, or more likely Ian missed Jan's reply, so I wanted
to double check.
> Right, but unless really urgent/important I think this is too late for
> 4.5.1 now and needs to be put on the list of backports for 4.5.2.
Jan, just to clarify, are you saying back portin
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, June 09, 2015 11:09 PM
> To: Wu, Feng
> Cc: andrew.coop...@citrix.com; george.dun...@eu.citrix.com; Tian, Kevin;
> Zhang, Yang Z; xen-devel@lists.xen.org; k...@xen.org
> Subject: Re: [RFC v2 09/15] Add a
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, June 09, 2015 11:06 PM
> To: Wu, Feng
> Cc: andrew.coop...@citrix.com; george.dun...@eu.citrix.com; Tian, Kevin;
> Zhang, Yang Z; xen-devel@lists.xen.org; k...@xen.org
> Subject: Re: [RFC v2 08/15] Update
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, June 10, 2015 2:18 PM
> To: Wu, Feng
> Cc: andrew.coop...@citrix.com; george.dun...@eu.citrix.com; Tian, Kevin;
> Zhang, Yang Z; xen-devel@lists.xen.org; k...@xen.org
> Subject: Re: [RFC v2 07/15] vt-d:
> -Original Message-
> From: xen-devel-boun...@lists.xen.org
> [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan Beulich
> Sent: Tuesday, June 09, 2015 11:20 PM
> To: Wu, Feng
> Cc: Tian, Kevin; k...@xen.org; george.dun...@eu.citrix.com;
> andrew.coop...@citrix.com; xen-devel@list
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, June 09, 2015 10:33 PM
> To: Wu, Feng
> Cc: andrew.coop...@citrix.com; george.dun...@eu.citrix.com; Tian, Kevin;
> Zhang, Yang Z; xen-devel@lists.xen.org; k...@xen.org
> Subject: Re: [RFC v2 07/15] vt-d:
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, June 10, 2015 2:49 PM
> To: Wu, Feng
> Cc: andrew.coop...@citrix.com; george.dun...@eu.citrix.com; Tian, Kevin;
> Zhang, Yang Z; xen-devel@lists.xen.org; k...@xen.org
> Subject: Re: [RFC v2 14/15] Suppr
>>> On 12.06.15 at 11:32, wrote:
> Ian, Jan,
>
> you seem to be disagreeing, or more likely Ian missed Jan's reply, so I
> wanted to double check.
>
>> Right, but unless really urgent/important I think this is too late for
>> 4.5.1 now and needs to be put on the list of backports for 4.5.2.
>
flight 58399 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58399/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumpuserxen-amd64 15
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 5
On Thu, Jun 11, 2015 at 09:52:44AM +0100, Ross Lagerwall wrote:
> The current code for allocating memory for PV guests batches the
> hypercalls to allocate memory by allocating 1024*1024 extents of order 0
> at a time. To make this faster, first try allocating extents of order 9
> (2 MiB) before fa
> On 12 Jun 2015, at 10:46, Jan Beulich wrote:
>
On 12.06.15 at 11:32, wrote:
>>
>> Even though having a released version of Xen which works out of the box with
>> OpenStack is pretty important.
>
> The release being stuck anyway, perhaps we can put them in with
> the understanding that
On 06/12/2015 03:41 PM, Paul Durrant wrote:
>> -Original Message-
>> From: Wen Congyang [mailto:we...@cn.fujitsu.com]
>> Sent: 12 June 2015 04:22
>> To: Paul Durrant; Yang Hongyang; Andrew Cooper; xen-devel@lists.xen.org
>> Cc: Wei Liu; Ian Campbell; guijianf...@cn.fujitsu.com;
>> yunhong.j
Ian Campbell writes ("Re: [PATCH OSSTEST] Arrange to upgrade microcode on x86
test hosts."):
> On Thu, 2015-06-11 at 16:39 +0100, Ian Jackson wrote:
> > If $c{prop} is undef, the logm will produce a warning. Maybe you want
> > //'' somewhere.
>
> I think that was a stray wip debug thing, I could
1: eliminate several explicit version checks
2: limit mapcount() looping
3: simplify shared entry v1 vs v2 handling
4: simplify page copying/clearing
5: fix/adjust gnttab_transfer()
6: make struct grant_mapping private
Signed-off-by: Jan Beulich
___
X
Ian Campbell writes ("[PATCH OSSTEST v2] Arrange to upgrade microcode on x86
test hosts."):
> Both Xen and Linux support extracting a microcode update from an
> initramfs early during boot. This requires prepending a suitable
> uncompressed cpio archive containing the necessary files to the
> init
>>> On 12.06.15 at 11:40, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, June 09, 2015 10:33 PM
>> >>> On 08.05.15 at 11:07, wrote:
>> > +remap_index = msi_desc->remap_index;
>> > +drhd = acpi_find_matched_drhd_unit(pci_dev);
>> > +if ( !drhd )
>> > +{
>>
>>> On 12.06.15 at 11:40, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >>> On 08.05.15 at 11:07, wrote:
>> > +static inline void setup_posted_irte(
>> > +struct iremap_entry *new_ire, struct pi_desc *pi_desc, uint8_t gvec)
>> > +{
>> > +new_ire->
By having nr_grant_entries() return zero when the grant table version
is still unset we can reduce the number of error paths and at once fix
grant_map_exists() running into the being removed ASSERT() when called
for a page owned by a domain not having its grant table set up yet.
Signed-off-by: Jan
The function also doesn't need to return counts; all its callers are
after is whether at least one entry of a certain kind exists. With that
there's no point for that loop to continue once the looked for
condition was found to be met by one entry. Rename the function to
match the changed behavior.
In a number of places both v1 and v2 pointers are being obtained when
none or just one suffices. Additionally in __acquire_grant_for_copy()
the flow of if/else-if can be slightly improved by re-ordering.
Signed-off-by: Jan Beulich
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@
... by making {copy,clear}_domain_page() available also on other than
x86.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -230,24 +230,6 @@ void unmap_domain_page(const void *ptr)
local_irq_restore(flags);
}
-void clear_domain_page(unsigne
- don't update shared entry's frame number for translated domains (as
MFNs shouldn't be exposed to such guests)
- for v1 grant table format, force copying of the page also when the
intended MFN doesn't fit in 32 bits (and the domain isn't translated)
- fix an apparent off-by-one error (it's unc
This documents that no entity outside of gnttab.c actually accesses
objects of that type.
Signed-off-by: Jan Beulich
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -113,6 +113,16 @@ struct gnttab_unmap_common {
goto _lbl; \
} while ( 0
>>> On 12.06.15 at 11:40, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, June 09, 2015 11:06 PM
>> >>> On 08.05.15 at 11:07, wrote:
>> > +static bool_t pi_find_dest_vcpu(struct domain *d, uint8_t dest_id,
>> > +uint8_t dest_mode, uint8_t
>
>>> On 12.06.15 at 11:40, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, June 09, 2015 11:09 PM
>> >>> On 08.05.15 at 11:07, wrote:
>> > This patch adds a new per-vCPU tasklet to wakeup the blocked
>> > vCPU. It can be used in the case vcpu_unblock cannot be called
>> >
Il 11/06/2015 17:42, Paul Durrant ha scritto:
This patch series re-works much of the code involved in emulation of port
and memory mapped I/O for HVM guests.
The code has become very convoluted and, at least by inspection, certain
emulations will apparently malfunction.
The series is broken dow
>>> On 12.06.15 at 11:40, wrote:
>> From: xen-devel-boun...@lists.xen.org
>> [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan Beulich
>> Sent: Tuesday, June 09, 2015 11:20 PM
>> >>> On 08.05.15 at 11:07, wrote:
>> > +{
>> > +struct vcpu *v;
>> > +unsigned int cpu = smp_processor
>>> On 12.06.15 at 11:40, wrote:
>
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Wednesday, June 10, 2015 2:49 PM
>> To: Wu, Feng
>> Cc: andrew.coop...@citrix.com; george.dun...@eu.citrix.com; Tian, Kevin;
>> Zhang, Yang Z; xen-devel@lists.xen.org; k...@x
> -Original Message-
> From: Wen Congyang [mailto:we...@cn.fujitsu.com]
> Sent: 12 June 2015 11:26
> To: Paul Durrant; Yang Hongyang; Andrew Cooper; xen-devel@lists.xen.org
> Cc: Wei Liu; Ian Campbell; guijianf...@cn.fujitsu.com;
> yunhong.ji...@intel.com; Eddie Dong; rshri...@cs.ubc.ca; Ia
flight 58422 rumpuserxen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58422/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 5 rumpuserxen-build fail REGR. vs. 33866
build-i386-rumpuserxe
On 06/12/2015 06:54 PM, Paul Durrant wrote:
>> -Original Message-
>> From: Wen Congyang [mailto:we...@cn.fujitsu.com]
>> Sent: 12 June 2015 11:26
>> To: Paul Durrant; Yang Hongyang; Andrew Cooper; xen-devel@lists.xen.org
>> Cc: Wei Liu; Ian Campbell; guijianf...@cn.fujitsu.com;
>> yunhong.j
Ian Campbell writes ("Re: [PATCH] libxl: libxl_internal.h: Clarify ao rule
against internal callers"):
> On Thu, 2015-06-11 at 17:57 +0100, Ian Jackson wrote:
> > Signed-off-by: Ian Jackson
> > CC: Ian Campbell
> > CC: Wei Liu
> > CC: Juergen Gross
>
> Acked-by: Ian Campbell
>
> AO_INITIATO
Hi,
On 11/06/2015 23:03, Wang, Wei W wrote:
On 11/06/2015 22:02, Julien Grall wrote:
On 11/06/2015 04:31, Wei Wang wrote:
-list_for_each(pos, &cpufreq_governor_list)
+if (policy->policy)
What if another cpufreq decides to use policy->policy?
What is "another cpufreq"? The "policy"
Hey,
During work on multiboot2 protocol support for Xen on EFI platform
I discovered that we need relocatable Xen early boot code (which is
mostly 32-bit code). More you can find here:
http://lists.xen.org/archives/html/xen-devel/2015-02/msg01257.html
I would like to focus on solution #1 describ
Juergen Gross writes ("Re: [Xen-devel] [PATCH] libxl: libxl_internal.h: Clarify
ao rule against internal callers"):
> Now it's 100% clear what to avoid.
>
> Acked-by: Juergen Gross
Thanks, pushed.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.
Chun Yan Liu writes ("Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API"):
> <21881.47707.526863.158...@mariner.uk.xensource.com>, Ian Jackson
> wrote:
> > Chunyan Liu writes ("[Xen-devel] [PATCH V4 3/7] libxl: add pvusb API"):
> > > +int libxl_device_usbctrl_getinfo(libxl_ctx *ctx, uint32_t
Ian Campbell writes ("Re: [Xen-devel] [PATCH v2 COLOPre 06/13] tools/libxl:
Introduce a new internal API libxl__domain_unpause()"):
> On Thu, 2015-06-11 at 17:09 +0800, Wen Congyang wrote:
> > If the public API creates a new AO, it is safe to call it directly?
>
> A public function which takes an
On 11/06/2015 21:41, Wang, Wei W wrote:
On 11/06/2015 22:02, Julien Grall wrote:
On 11/06/2015 04:27, Wei Wang wrote:
diff --git a/xen/include/acpi/cpufreq/cpufreq.h
b/xen/include/acpi/cpufreq/cpufreq.h
index d10e4c7..71bb45c 100644
--- a/xen/include/acpi/cpufreq/cpufreq.h
+++ b/xen/include
Jan Beulich writes ("Re: [Xen-devel] libxl backports for 4.4 and 4.5"):
> On 12.06.15 at 11:32, wrote:
> > you seem to be disagreeing, or more likely Ian missed Jan's reply, so I
> > wanted to double check.
Thanks for pointing this out, Lars. I had just spotted it myself.
> The release being s
On 15.05.2015 21:44, Konrad Rzeszutek Wilk wrote:
[...]
> ## Hypercalls
>
> We will employ the sub operations of the system management hypercall (sysctl).
> There are to be four sub-operations:
>
> * upload the payloads.
> * listing of payloads summary uploaded and their state.
> * getting an
On 11/06/2015 22:01, Wang, Wei W wrote:
On 11/06/2015 22:06, Julien Grall wrote:
On 11/06/2015 04:28, Wei Wang wrote:
cpufreq_cpu_policy is used in intel_pstate_set_pstate(), so we change
to NULL it after the call of cpufreq_driver->exit. Otherwise, a
calltrace will show up on your screen due
On 12/06/2015 04:32, Ian Campbell wrote:
On Thu, 2015-06-11 at 14:38 -0700, Manish Jaggi wrote:
On Wednesday 10 June 2015 12:21 PM, Julien Grall wrote:
Hi,
On 10/06/2015 08:45, Ian Campbell wrote:
4. DomU access / assignment PCI device
--
When a device i
On 11/06/2015 17:43, Chris (Christopher) Brand wrote:
Hi Julien,
Hi Chris,
The patch does work exactly as advertised.
When I used dtc to convert CONFIG_DTB_FILE from dtb to dts, I could see that it didn't in
fact have a timer clock-frequency node. After re-creating the dtb and rebuilding
> -Original Message-
> From: Fabio Fantoni [mailto:fabio.fant...@m2r.biz]
> Sent: 12 June 2015 11:44
> To: Paul Durrant; xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH v2 00/17] x86/hvm: I/O emulation cleanup
> and fix
>
> Il 11/06/2015 17:42, Paul Durrant ha scritto:
> >
> -Original Message-
> From: Wen Congyang [mailto:we...@cn.fujitsu.com]
> Sent: 12 June 2015 12:10
> To: Paul Durrant; Yang Hongyang; Andrew Cooper; xen-devel@lists.xen.org
> Cc: Wei Liu; Ian Campbell; guijianf...@cn.fujitsu.com;
> yunhong.ji...@intel.com; Eddie Dong; rshri...@cs.ubc.ca; Ia
On 08.06.2015 17:19, Konrad Rzeszutek Wilk wrote:q
[...]
>>> There is a nice part of the old code check - you
>>> can check (and deal with) patching an already patched code.
>>> As in, if the payload was configured to be applied on top of an already
>>> patched function it would patch nicely. But i
Ian Jackson writes ("Re: [Xen-devel] libxl backports for 4.4 and 4.5"):
> I propose to push all of these today, unless you object. I will
> double-check with you on irc.
Now done.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xe
Ian Campbell writes ("Backport request "libxl: In libxl_set_vcpuonline check
for maximum number of VCPUs against the cpumap." (Was: Re: [Bug report]
Security issue in "xl vcpu-set")"):
> commit d83bf9d224eeb5b73b93c2703f7dba4473cfa89c
> Author: Konrad Rzeszutek Wilk
> Date: Fri Apr 3 16:02:29
On Fri, 2015-06-12 at 07:41 -0400, Julien Grall wrote:
> I was suggesting to expose the host layout to the guest layout (similar
> to e820).
We do this on x86 only as a workaround for broken hardware (essentially
magic system devices which bypass the IOMMU).
We shouldn't do this on ARM by defau
>>> On 12.06.15 at 13:14, wrote:
> Here I do not want to discuss GRUB2 and multiboot2 protocol support details
> for relocatable images. It is not needed. It is sufficient to know that it
> is able to put loaded image anywhere in available memory below 4 GiB. Loaded
> image is informed about its b
On Mon, Jun 08, 2015 at 11:43:11AM +0800, Yang Hongyang wrote:
> Currently, libxl__domain_unpause() only supports
> qemu-xen-traditional. Update it to support qemu-xen.
>
> Signed-off-by: Wen Congyang
> Signed-off-by: Yang Hongyang
This looks very similar to an existing function called
libxl__d
> On 12 Jun 2015, at 13:01, Ian Jackson wrote:
>
> Ian Jackson writes ("Re: [Xen-devel] libxl backports for 4.4 and 4.5"):
>> I propose to push all of these today, unless you object. I will
>> double-check with you on irc.
>
> Now done.
Thanks
Lars
__
On 06/12/15 02:25, Jan Beulich wrote:
On 12.06.15 at 00:10, wrote:
>> On 06/05/15 06:54, Ian Campbell wrote:
>>> It would be really useful to see a comprehensive list of exactly what
>>> guest ring3 access to the vmware port actually enables i.e. a list of
>>> specific features which require
On Thu, 2015-06-11 at 10:40 +0100, Ian Campbell wrote:
> ## Command Queue Virtualisation
>
> The command translation/emulation in this design has been arranged to
> be as cheap as possible (e.g. in many cases the actions are NOPs),
> avoiding previous concerns about the length of time which an emu
On Mon, Jun 08, 2015 at 11:43:14AM +0800, Yang Hongyang wrote:
> From: Wen Congyang
>
> In colo mode, slave needs to send data to master, but the io_fd
> only can be written in master, and only can be read in slave.
> Save recv_fd in domain_suspend_state, and send_fd in
> domain_create_state.
>
Hi Ian,
On 12/06/2015 04:52, Ian Campbell wrote:
On Fri, 2015-06-12 at 14:07 +0530, Vijay Kilari wrote:
So pLPIs must be routed at device assignment time because in the vLPI
configuration table trap there is no mapping back to a single pLPI.
I just remembered the exact reason that made use to
On 12/06/2015 08:55, Ian Campbell wrote:
On Thu, 2015-06-11 at 10:40 +0100, Ian Campbell wrote:
## Command Queue Virtualisation
The command translation/emulation in this design has been arranged to
be as cheap as possible (e.g. in many cases the actions are NOPs),
avoiding previous concerns a
1 - 100 of 199 matches
Mail list logo
