flight 58401 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58401/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-libvirt 11 guest-start fail like 58334
test-amd64-amd64-libvirt 11 gu
>>> On 12.06.15 at 04:40, wrote:
>> > >>> On 10.06.15 at 16:05, wrote:
>> >>> On 03.06.15 at 09:49, wrote:
>> > For Context Invalidation and IOTLB invalidation without Device-TLB
>> > invalidation, Invalidation Queue flushes synchronous invalidation as
>> > before(This is a tradeoff and the
On 2015/6/11 17:28, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Thursday, June 11, 2015 9:15 AM
This patch extends the existing hypercall to support rdm reservation policy.
We return error or just throw out a warning message depending on whether
the policy is "strict" or "relaxed" when reserving
>>> 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 it.
>
> Ok, I have done some testing. Her
On 2015/6/12 13:59, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Friday, June 12, 2015 1:58 PM
On 2015/6/12 10:43, Chen, Tiejun wrote:
On 2015/6/11 22:07, Tim Deegan wrote:
At 17:31 +0800 on 11 Jun (1434043916), Chen, Tiejun wrote:
while ( base_pfn < end_pfn )
{
-int er
flight 58398 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58398/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 56492
test-amd64-i386-xl-qemuu-win7-amd64 1
> From: Chen, Tiejun
> Sent: Friday, June 12, 2015 1:58 PM
>
> On 2015/6/12 10:43, Chen, Tiejun wrote:
> > On 2015/6/11 22:07, Tim Deegan wrote:
> >> At 17:31 +0800 on 11 Jun (1434043916), Chen, Tiejun wrote:
> >while ( base_pfn < end_pfn )
> >{
> > -int err = i
On 2015/6/12 10:43, Chen, Tiejun wrote:
On 2015/6/11 22:07, Tim Deegan wrote:
At 17:31 +0800 on 11 Jun (1434043916), Chen, Tiejun wrote:
while ( base_pfn < end_pfn )
{
-int err = intel_iommu_map_page(d, base_pfn, base_pfn,
-
IOMMUF_readable|IOMMUF_writable);
+int e
For various reasons, I need to unload and load a new netfront from a
relatively modern distro (say Fedora 21) while running under RHEL5's
dom0. On rmmod of the netfront in domU, the netback in dom0 seems to go
immediately to Closed and skips going through Closing. So the netback
fails to release
flight 58397 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58397/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 9 debian-install fail REGR. vs. 52209-bisect
test-amd64-amd64-pair
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Thursday, June 11, 2015 11:20 PM
> To: Pang, LongtaoX
> Cc: xen-devel@lists.xen.org; ian.campb...@citrix.com; wei.l...@citrix.com; Hu,
> Robert
> Subject: RE: [OSSTEST Nested PATCH v11 6/7] Compose the mai
On 06/11/2015 06:57 PM, Ian Jackson wrote:
Signed-off-by: Ian Jackson
CC: Ian Campbell
CC: Wei Liu
CC: Juergen Gross
---
tools/libxl/libxl_internal.h |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
inde
> -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; Hu,
> Robert
> Subject: RE: [OSSTEST Nested PATCH v11 5/7] Add new script
On Thu, 2015-06-11 at 16:19 +0100, Ian Jackson wrote:
> Pang, LongtaoX writes ("RE: [OSSTEST Nested PATCH v11 6/7] Compose the main
> recipe of nested test job"):
> ...
>
> (Ian C has answered some of your comments. On the others:)
>
> > > I think you probably want to run leak-check on the L1.
On 06/11/2015 08:54 PM, Yang Hongyang wrote:
[...]
this patch now.
Ok, this really is a historical patch...
Having tested, it is ok to drop this patch now.
Thanks
Wen Congyang
In our implementation, we don't start a new emulator. The codes can work,
but some bugs may be not triggered
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: Thursday, June 11, 2015 10:54 PM
>
> On 06/11/2015 04:17 AM, Tian, Kevin wrote:
> >> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
>
> >> switch ( vendor )
> >> {
> >> case X86_VENDOR_AMD:
> >> -
On 06/11/2015 09:25 PM, Paul Durrant wrote:
>> -Original Message-
>> From: Yang Hongyang [mailto:yan...@cn.fujitsu.com]
>> Sent: 11 June 2015 13:59
>> To: Paul Durrant; Wen Congyang; Andrew Cooper; xen-devel@lists.xen.org
>> Cc: Wei Liu; Ian Campbell; guijianf...@cn.fujitsu.com;
>> yunhong.
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" is per-CPU struct.
> > +gov
On 2015/6/11 22:07, Tim Deegan wrote:
At 17:31 +0800 on 11 Jun (1434043916), Chen, Tiejun wrote:
while ( base_pfn < end_pfn )
{
-int err = intel_iommu_map_page(d, base_pfn, base_pfn,
- IOMMUF_readable|IOMMUF_writable);
+int err
>> >>> On 10.06.15 at 16:05, wrote:
> >>> On 03.06.15 at 09:49, wrote:
Jan, thanks for your review!!
> > Design Overview
> > =
> > This design implements a non-spinning model for Device-TLB
> > invalidation - using an interrupt based mechanism. Each domain
> > maintains a invalidati
On Thu, Jun 11, 2015 at 09:05:06PM +0800, Chen Baozi wrote:
> 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, whic
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_update() can be a thing
>> wrapper around the hyp
flight 58392 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58392/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 6 xen-boot fail REGR. vs. 58264
test-amd64-i386-xl-qemuu-win7
On 2015/6/11 20:52, Tim Deegan wrote:
Hi,
At 09:15 +0800 on 11 Jun (1434014109), Tiejun Chen wrote:
* Two changes for runtime cycle
patch #2,xen/x86/p2m: introduce set_identity_p2m_entry, on hypervisor side
a>. Introduce paging_mode_translate()
Otherwise, we'll see this error when bo
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 to the reference of a NULL
> >
Hi Julien,
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/acpi/cpufreq/cp
> -Original Message-
> From: Tim Deegan [mailto:t...@xen.org]
> Sent: Thursday, June 11, 2015 10:20 PM
> To: Li, Liang Z
> Cc: xen-devel@lists.xen.org; k...@xen.org; jbeul...@suse.com;
> andrew.coop...@citrix.com; Tian, Kevin; Zhang, Yang Z
> Subject: Re: [RESEND] nested EPT: fix the handl
On Thu, Jun 11, 2015 at 05:23:16PM -0600, Toshi Kani wrote:
> On Thu, 2015-06-11 at 13:36 -0700, Luis R. Rodriguez wrote:
> :
> > Pending RIP MTRR patches
> >
> >
> > There are a few pending series so I wanted to provide a status update
> > on those series.
> >
> > mtrr: bur
On Thu, 2015-06-11 at 13:36 -0700, Luis R. Rodriguez wrote:
:
> Pending RIP MTRR patches
>
>
> There are a few pending series so I wanted to provide a status update
> on those series.
>
> mtrr: bury MTRR - unexport mtrr_add() and mtrr_del()
>
> This is the nail on the MTRR
flight 58387 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58387/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl 17 guest-localmigrate/x10fail REGR. vs. 58318
Regressions which a
On 06/05/15 06:54, Ian Campbell wrote:
> On Fri, 2015-06-05 at 10:31 +0100, Jan Beulich wrote:
>>> I'm talking about cost-benefits analysis. What's the benefit of
>>> accepting this patch, and is it worth the cost?
>>
>> The basic idea of allowing guests originally having got installed on
>> VMwar
On 06/08/15 06:05, George Dunlap wrote:
> On 06/04/2015 12:28 PM, Don Slutz wrote:
>> On 06/03/15 13:09, George Dunlap wrote:
>>> On 05/22/2015 04:50 PM, Don Slutz wrote:
This adds synchronization of the 6 vcpu registers (only 32bits of
them) that vmport.c needs between Xen and QEMU.
Hi Julien,
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 Xen, "ls /proc/device-tree/timer/" shows a clock-frequency file.
When
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 domU, provision has to be made such that
it can
access the MMIO space of the device
The series to bury direct MTRR use is almost all in and on its way to
v4.2. As the pending series continue slowly to be merged I wanted to
take the time to reiterate the justification for these changes in
hopes it may help those still reviewing some of these patches which
are pending and to help do
From: "Luis R. Rodriguez"
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
In order to h
From: "Luis R. Rodriguez"
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
In order to h
On Wed, Jun 10, 2015 at 11:34 PM, Jan Beulich wrote:
On 10.06.15 at 19:22, wrote:
>> On Wed, Jun 10, 2015 at 2:37 AM, Jan Beulich wrote:
>> On 10.06.15 at 11:26, wrote:
On Wed, 2015-06-10 at 10:15 +0100, Jan Beulich wrote:
> >>> On 10.06.15 at 10:56, wrote:
> > On Tue, 20
flight 58382 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58382/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail REGR. vs. 58290
Regression
From: "Luis R. Rodriguez"
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
In order to h
From: "Luis R. Rodriguez"
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
In order to h
On 6/11/2015 10:38 AM, Ian Campbell wrote:
On Thu, 2015-06-11 at 17:24 +0100, Wei Liu wrote:
Since the backend is in DOM0, and is around longer than the DOMUs, this
happens first. It's that interaction that I'd like a little more text on.
If it exists.
I'm not completely sure what you're re
Anthony PERARD writes ("libxl backports for 4.4 and 4.5"):
> Hi Jan and Ian,
>
> Could we have the following commit been backport to 4.4?
> 9369988 libxl: event handling: Break out ao_work_outstanding
> f1335f0 libxl: event handling: ao_inprogress does waits while reports
> outstanding
> 4783c99
Wei Liu writes ("Re: [PATCH V3 3/6] libxl: add pvusb API"):
> On Mon, May 18, 2015 at 09:20:43PM -0600, Chun Yan Liu wrote:
> > Thanks, I'm updating that. But maybe like pci_add and pci_remove functions,
> > will add a 'starting' flag to indicate hotplug or creation.
> > Looking at DEFINE_DEVICE_AD
Signed-off-by: Ian Jackson
CC: Ian Campbell
CC: Wei Liu
CC: Juergen Gross
---
tools/libxl/libxl_internal.h |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 465..bfc0729 100644
--- a/tools/libxl/lib
flight 58384 qemu-upstream-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58384/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs.
57876
Re
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 to
completely finish my review this, but here's what I have:
> --- /dev/null
> +++ b/docs/misc/pvusb.txt
> @@ -0,0 +1,243 @@
> +1.
On Thu, 2015-06-11 at 17:24 +0100, Wei Liu wrote:
> > Since the backend is in DOM0, and is around longer than the DOMUs, this
> > happens first. It's that interaction that I'd like a little more text on.
> > If it exists.
>
> I'm not completely sure what you're referring to. That probably only
>
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
initrd.
Xen also supports loading the microcode cpio from any multiboot
module, but for in order to allo
flight 58381 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58381/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail blocked in 57828
test-amd64-i386-
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/xentrace/analyze.h | 13 -
1 file changed, 13 deletions(-)
diff --git a/tools/xentrace/analyze.h b/tools/xentrace/analyze.h
index 40ee551..9b3651a 100644
--- a/tools/xentrace/
Result of "sed -i 's@[[:blank:]]\+$@@' tools/xentrace/xenalyze.c"
Signed-off-by: Olaf Hering
Acked-by: George Dunlap
Acked-by: Wei Liu
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/xentrace/xenalyze.c | 350 +++---
1 f
Signed-off-by: Olaf Hering
Acked-by: George Dunlap
Acked-by: Wei Liu
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/xentrace/xenalyze.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index fef8aea..1
Signed-off-by: Olaf Hering
Acked-by: George Dunlap
Acked-by: Wei Liu
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/xentrace/xenalyze.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
in
Having xenalyze in the source tree makes it much easier to keep private
debug code in hypervisor and xenalyze in sync. It helped alot while
debugging the root cause for commit 607e8494c42397fb249191904066cace6ac9a880.
changes between v5 and v5:
- remove unused cpumask_t instead bumping NR_CPUS
-
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/xentrace/xenalyze.c | 73 ++-
1 file changed, 66 insertions(+), 7 deletions(-)
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze
Signed-off-by: Olaf Hering
Acked-by: George Dunlap
Acked-by: Wei Liu
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/xentrace/xenalyze.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
in
Since xenalyze is now upstream its Open Source and part of the given
release.
Signed-off-by: Olaf Hering
Acked-by: George Dunlap
Acked-by: Wei Liu
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/xentrace/xenalyze.c | 1 -
1 file changed, 1 deletion(-)
diff --
On 06/11/2015 12:05 AM, Jan Beulich wrote:
On 10.06.15 at 18:39, wrote:
>> On 06/10/2015 12:43 AM, Jan Beulich wrote:
>> On 10.06.15 at 02:09, wrote:
Design
==
>>>
>>> Reads all quite reasonable; just one minor remark:
>>>
- Core altp2m functionality
A new al
On Thu, Jun 11, 2015 at 05:08:57PM +0100, Ian Jackson wrote:
> Chunyan Liu writes ("[Xen-devel] [PATCH V4 1/7] libxl: export some functions
> for pvusb use"):
> > Signed-off-by: Chunyan Liu
> > Signed-off-by: Simon Cao
> > Acked-by: Wei Liu
> ...
> > /* generic callback for devices that only n
Juergen Gross writes ("Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API"):
> The second async operation is being called with ao_how being NULL, but
> I'm not sure whether this is allowed (libxl_internal.h comments are not
> clear for me regarding such a scenario).
It is not allowed.
I'll have
elf_parse_bsdsyms expects the second paramater to be a physical address, not
a virtual one.
Signed-off-by: Roger Pau Monné
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Tim Deegan
---
xen/common/libelf/libelf-dominfo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
This two patches fix BSD symtab/strtab loading when
XEN_ELFNOTE_PADDR_OFFSET is different than XEN_ELFNOTE_VIRT_BASE. They are
fairly small fixes, which I hope can be backported to stable branches once
accepted.
Thanks, Roger.
___
Xen-devel mailing list
On Thu, Jun 11, 2015 at 06:32:08AM -0600, Linda wrote:
> On 6/11/2015 4:43 AM, Wei Liu wrote:
> >On Wed, Jun 10, 2015 at 07:45:15PM -0600, Linda wrote:
> >>Hello all,
> >> I will be writing a xen front and back-end pair for a 9p transport. I
> >>have two areas where I'm still a little more mud
On 06/11/2015 05:06 AM, Tim Deegan wrote:
> At 00:09 +0100 on 11 Jun (1433981379), Andrew Cooper wrote:
>> On 10/06/15 20:41, Ed White wrote:
>>> On 06/10/2015 11:23 AM, Andrew Cooper wrote:
Also, hardware accelerated altp2m is mutually exclusive with EPT PML, as
we have no way of determi
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 than that.
> Current libxl_read_file_contents will treat it as error when file size
> and actual file content differs, so reading
> On 10 Jun 2015, at 10:51, Andrew Cooper wrote:
>
> On 10/06/15 10:42, Lars Kurth wrote:
>> Alright,
>> if nobody is willing to come up with a definition of
>> experimental/preview/supported/deprecated, I will based on what I have seen
>> Lars
>
> I was planning to start a document to this ef
Chunyan Liu writes ("[Xen-devel] [PATCH V4 1/7] libxl: export some functions
for pvusb use"):
> Signed-off-by: Chunyan Liu
> Signed-off-by: Simon Cao
> Acked-by: Wei Liu
...
> /* generic callback for devices that only need to set ao_complete */
> -static void device_addrm_aocomplete(libxl__egc
>>> On 11.06.15 at 17:14, wrote:
> As a side question, will Xen boot on Cyrix (or are they VIA)?
At some point I made that work; the box I have for that has
developed a problem though (turning itself off at random
points in time), so I can't really try anymore whether this continues
to work.
Jan
xc_dom_load_elf_symtab was incorrectly trying to perform the same
calculations already done in elf_parse_bsdsyms when load == 0 is used.
Instead of trying to repeat the calculations, just trust what
elf_parse_bsdsyms has already accounted for.
This also simplifies the code by allowing the non-load
>>> On 11.06.15 at 17:39, wrote:
> On 06/11/2015 03:22 PM, Jan Beulich wrote:
> On 11.06.15 at 15:03, wrote:
>>> @@ -946,6 +948,8 @@ int __init construct_dom0(
>>> if ( (rc = elf_xen_parse(&elf, &parms)) != 0 )
>>> goto out;
>>>
>>> +process_pending_softirqs();
>>
>> For t
>>> On 11.06.15 at 17:29, wrote:
> Could we have the following commit been backport to 4.4?
> 9369988 libxl: event handling: Break out ao_work_outstanding
> f1335f0 libxl: event handling: ao_inprogress does waits while reports
> outstanding
> 4783c99 libxl: In domain death search, start search at
On Thu, Jun 11, George Dunlap wrote:
> First, it looks like maybe this wasn't based on 24308507be1d, but on
> 8083183a7238? At least there seems to be changes in it that aren't in
> the other one.
Where is 8083183a7238? I have this as HEAD:
# changeset: 150:24308507be1d
# tag: tip
#
On 6/11/2015 4:43 AM, Wei Liu wrote:
On Wed, Jun 10, 2015 at 07:45:15PM -0600, Linda wrote:
Hello all,
I will be writing a xen front and back-end pair for a 9p transport. I
have two areas where I'm still a little more muddled than I'd like to be.
Can anyone please recommend a good art
On Thu, 2015-06-11 at 16:39 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST] 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
> > uncompres
Use an ioreq_t rather than open coded state, size, dir and data fields
in struct hvm_vcpu_io. This also allows PIO completion to be handled
similarly to MMIO completion by re-issuing the handle_pio() call.
Signed-off-by: Paul Durrant
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/a
...otherwise they will simply carry on to the next page using a normal
linear-to-phys translation.
Signed-off-by: Paul Durrant
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/emulate.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/xen/arch
The code in hvmemul_do_io() that tracks large reads or writes, to avoid
re-issue of component I/O, is defeated by accesses across a page boundary
because it uses physical address. The code is also only relevant to memory
mapped I/O to or from a buffer.
This patch re-factors the code and moves it i
The is_mmio parameter can be inferred from the ioreq type.
Signed-off-by: Paul Durrant
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/emulate.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/e
...in hvmemul_read/write()
Add hvmemul_phys_mmio_access() and hvmemul_linear_mmio_access() functions
to reduce code duplication.
Signed-off-by: Paul Durrant
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/emulate.c | 244 +---
1
By removing the HVMIO_dispatched state and making all pending emulations
(i.e. all those not handled by the hypervisor) use HVMIO_awating_completion,
various code-paths can be simplified.
Signed-off-by: Paul Durrant
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/emulat
Emulation request status is already covered by STATE_IOREQ_XXX values so
just use those. The mapping is:
HVMIO_none-> STATE_IOREQ_NONE
HVMIO_awaiting_completion -> STATE_IOREQ_READY
HVMIO_completed -> STATE_IORESP_READY
Signed-off-by: Paul Durrant
Cc: Keir Fraser
Cc: J
If hvmemul_do_io_addr() is called to complete a previously issued
emulation then there is no need to acquire the RAM pages again. There
is also no need to re-calculate the value of *reps, providing
hvmemul_do_io() updates it when returning X86EMUL_OKAY.
Signed-off-by: Paul Durrant
Cc: Keir Fraser
flight 58383 qemu-upstream-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58383/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass
test-amd64-i386-xl-qemuu-
By removing the calls in hvmemul_do_io() (which is replaced by a single
assignment) and hvm_complete_assist_request() (which is replaced by a
call to process_portio_intercept() with a suitable set of ops) then
hvm_io_assist() can be moved into hvm.c and made static (and hence be a
candidate for inl
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 down into 17 patches (which are also available in
m
The implementation of mmio and portio intercepts is unnecessarily different.
This leads to much code duplication. This patch unifies much of the
intercept handling, leaving only distinct handlers for stdvga mmio and dpci
portio. Subsequent patches will unify those handlers.
Signed-off-by: Paul Dur
Currently hvmemul_do_io() handles paging for I/O to/from a guest address
inline. This causes every exit point to have to execute:
if ( ram_page )
put_page(ram_page);
This patch introduces wrapper hvmemul_do_io_addr() and
hvmemul_do_io_buffer() functions. The latter is used for I/O to/from a X
The state of in-flight I/O and how its completion will be handled are
logically separate and conflating the two makes the code unnecessarily
confusing.
Signed-off-by: Paul Durrant
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/hvm.c | 42 +
...and error handling"
NOTE: A straight reversion was not possible because of subsequent changes
in the code so this at least partially a manual reversion.
By limiting hvmemul_do_io_addr() to reps falling within the pages on which
a reference has already been taken, we can guarantee that ca
It's clear from the following check in hvmemul_rep_movs:
if ( sp2mt == p2m_mmio_direct || dp2mt == p2m_mmio_direct ||
(sp2mt == p2m_mmio_dm && dp2mt == p2m_mmio_dm) )
return X86EMUL_UNHANDLEABLE;
that mmio <-> mmio copy is not handled. This means the code in the
stdvga mmio i
The check is done at the wrong point (since it is irrelevant if the
I/O is to be handled by the hypervisor) and its functionality can be
covered by returning X86EMUL_UNHANDLEABLE from hvm_send_assist_req()
instead.
This patch also removes the domain_crash() call from
hvm_send_assist_req(). Returni
The struct just contains three methods and no data, so the name
hvm_mmio_ops more accurately reflects its content. A subsequent patch
introduces a new structure which more accurately warrants the name
hvm_mmio_handler so doing the rename in this purely cosmetic patch avoids
conflating functional an
This patch re-works the dpci portio intercepts so that they can be unified
with standard portio handling thereby removing a substantial amount of
code duplication.
Signed-off-by: Paul Durrant
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/hvm.c |2 +
xen/
Ian Campbell writes ("[PATCH OSSTEST] 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
> initrd.
On 06/11/2015 03:22 PM, Jan Beulich wrote:
On 11.06.15 at 15:03, wrote:
@@ -946,6 +948,8 @@ int __init construct_dom0(
if ( (rc = elf_xen_parse(&elf, &parms)) != 0 )
goto out;
+process_pending_softirqs();
For this one I'm not sure whether it shouldn't really go somewhere
Hi Jan and Ian,
Could we have the following commit been backport to 4.4?
9369988 libxl: event handling: Break out ao_work_outstanding
f1335f0 libxl: event handling: ao_inprogress does waits while reports
outstanding
4783c99 libxl: In domain death search, start search at first domid we want
188e9c
At 15:51 +0100 on 05 Jun (1433519478), Jan Beulich wrote:
> >>> On 02.06.15 at 18:26, wrote:
> > Performance analysis of aggregate network throughput with many VMs
> > shows that performance is signficantly limited by contention on the
> > maptrack lock when obtaining/releasing maptrack handles fr
Hi Chen,
On 11/06/2015 09:05, Chen Baozi wrote:
From: Chen Baozi
When a guest uses vGICv2, the maximum number of vCPU it can support
should not be as many as MAX_VIRT_CPUS, which will be more than 8
when GICv3 is used on arm64.
This sentence is not clear to me. What about:
"Each vGIC driver
Hi Chen,
On 11/06/2015 09:05, Chen Baozi wrote:
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
1 - 100 of 281 matches
Mail list logo
