Il 11/06/2015 12:06, Zir Blazer ha scritto:
Since I'm not a developer I may be peeking my nose a bit too far, but based on
what I know, I think that enabling AHCI by default would be a compatibility
suicide. I'm not sure about Linux and Windows Vista/7/8+, but at least for
Windows XP based VMs
> 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?
> with shared RMRR simply since the case of shared RMRR is
> a rare case according to our previous experiences. But
> late we can group these devices which
On 11/06/15 11:15, Jan Beulich wrote:
> ... when the domain pointer is already available or such operations occur
> frequently in a function. There's no particular ordering requirement
> between the individual patches, they only all do the same thing to
> different areas of code.
>
> 1: domctl: pre
On Thu, 2015-06-11 at 11:20 +0100, Jan Beulich wrote:
> ... when the domain pointer is already available.
>
> Signed-off-by: Jan Beulich
Acked-by: Ian Campbell
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Thu, 2015-06-11 at 09:52 +, Pang, LongtaoX wrote:
> I have checked nested job testid, as below:
> #./standalone run-job --simulate -h dummy test-amd64-amd64-qemuu-nested |
> grep testid
> 2015-06-11 09:46:37 Z standalone.test-amd64-amd64-qemuu-nested == 1
> testid build-check(1) ==
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 article on either grant tables or the
On 11/06/15 09:41, Ian Campbell wrote:
> On Thu, 2015-06-11 at 10:07 +0800, Yang Hongyang wrote:
>> On 06/10/2015 11:20 PM, Ian Campbell wrote:
>>> On Mon, 2015-06-08 at 11:43 +0800, Yang Hongyang wrote:
When we are under COLO, we will send dirty page bitmap info from
secondary to primary
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
At 14:15 +0100 on 10 Jun (1433945712), Jan Beulich wrote:
> >>> On 10.06.15 at 14:34, wrote:
> > * XEN_ELFNOTE_PADDR_OFFSET: the offset of the ELF paddr field from the
> >actual required physical address.
>
> Why would that be needed? I.e. why would there ever be an offset?
I had the same q
On 08/06/15 13:06, Juergen Gross wrote:
> Check whether the hypervisor supplied p2m list is placed at a location
> which is conflicting with the target E820 map. If this is the case
> relocate it to a new area unused up to now and compliant to the E820
> map.
>
> As the p2m list might by huge (up
On 06/11/2015 06:20 PM, Paul Durrant wrote:
>> -Original Message-
>> From: Wen Congyang [mailto:we...@cn.fujitsu.com]
>> Sent: 11 June 2015 09:48
>> To: Paul Durrant; Andrew Cooper; Yang Hongyang; xen-devel@lists.xen.org
>> Cc: Wei Liu; Ian Campbell; guijianf...@cn.fujitsu.com;
>> yunhong.j
On 11/06/2015 02:12, Olaf Hering wrote:
On Wed, Jun 10, Julien Grall wrote:
There is also a variable MAX_CPUS defined to 256. which is used every.
You are right, while forwarding an old patch (from memory) I changed the
wrong place. MAX_CPUS is already at 256 so no change is strictly
necces
Ian Campbell writes ("Re: 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")"):
> On Mon, 2015-06-08 at 11:35 +0100, Ian Jackson wrote:
> > I'm afraid I'm still not clear about when the fa
On Wed, 2015-06-10 at 14:21 +0100, George Dunlap wrote:
> On 06/10/2015 01:55 PM, George Dunlap wrote:
> > This reverts commit c1d322e6048796296555dd36fdd102d7fa2f50bf.
> >
> > The original commit fixes a bug when assigning a large number of
> > devices which require option roms to a guest. (One
On Thu, 2015-06-11 at 11:45 +0100, Andrew Cooper wrote:
> On 11/06/15 09:41, Ian Campbell wrote:
> > On Thu, 2015-06-11 at 10:07 +0800, Yang Hongyang wrote:
> >> On 06/10/2015 11:20 PM, Ian Campbell wrote:
> >>> On Mon, 2015-06-08 at 11:43 +0800, Yang Hongyang wrote:
> When we are under COLO,
On Thu, Jun 11, 2015 at 10:37:05AM +0100, Ian Campbell wrote:
> On Thu, 2015-06-11 at 17:20 +0800, Chen Baozi wrote:
> > On Fri, Jun 05, 2015 at 05:22:56PM +0100, Ian Campbell wrote:
> > > On Mon, 2015-06-01 at 20:56 +0800, Chen Baozi wrote:
> > > > From: Chen Baozi
> > > >
> > > > evtchn_init wi
>>> On 11.06.15 at 12:52, wrote:
> 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
Thursday, June 11, 2015, 9:47:47 AM, you wrote:
On 10.06.15 at 22:53, wrote:
>> --- a/hw/xen/xen_pt.c
>> +++ b/hw/xen/xen_pt.c
>> @@ -785,7 +785,9 @@ out:
>> xen_host_pci_set_word(&s->real_device, PCI_COMMAND,
>>pci_get_word(d->config + PCI_COMMAND)
On 10/06/15 12:36, Ian Campbell wrote:
> +
> +#define XTL_NEW_LOGGER(LOGGER,buffer) ({\
> +xentoollog_logger_##LOGGER *new_consumer; \
> +\
> +(buffer).vtable.vm
>>> On 11.06.15 at 12:33, wrote:
> On 11/06/15 11:15, Jan Beulich wrote:
>> ... when the domain pointer is already available or such operations occur
>> frequently in a function. There's no particular ordering requirement
>> between the individual patches, they only all do the same thing to
>> dif
flight 58373 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58373/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
test-amd64-i386-xl-qemuu-win7-amd64 16 gues
Commit 8a753b3f1c ("efi: fix allocation problems if ExitBootServices()
fails") replaced the use of a static (and hence zero-initialized)
variable by an automatic (and hence uninitialized) one.
Also drop the variable introduced by that commit in favor of re-using
another available and suitable one.
On Thu, 2015-06-11 at 12:20 +0100, Andrew Cooper wrote:
> On 10/06/15 12:36, Ian Campbell wrote:
> > +
> > +#define XTL_NEW_LOGGER(LOGGER,buffer) ({\
> > +xentoollog_logger_##LOGGER *new_consumer; \
> > +
Hi Ian,
On 11/06/2015 04:56, Ian Campbell wrote:
On Wed, 2015-06-10 at 15:21 -0400, 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
On Thu, 2015-06-11 at 12:18 +0100, Jan Beulich wrote:
> >>> On 11.06.15 at 12:52, wrote:
> > 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
> >
On 06/11/2015 12:35 PM, Jan Beulich wrote:
Commit 8a753b3f1c ("efi: fix allocation problems if ExitBootServices()
fails") replaced the use of a static (and hence zero-initialized)
variable by an automatic (and hence uninitialized) one.
Also drop the variable introduced by that commit in favor of
Hi Chen,
On 11/06/2015 07:16, Chen Baozi wrote:
On Thu, Jun 11, 2015 at 10:37:05AM +0100, Ian Campbell wrote:
On Thu, 2015-06-11 at 17:20 +0800, Chen Baozi wrote:
On Fri, Jun 05, 2015 at 05:22:56PM +0100, Ian Campbell wrote:
On Mon, 2015-06-01 at 20:56 +0800, Chen Baozi wrote:
From: Chen Bao
On Thu, 2015-06-11 at 12:35 +0100, Jan Beulich wrote:
> Commit 8a753b3f1c ("efi: fix allocation problems if ExitBootServices()
> fails") replaced the use of a static (and hence zero-initialized)
> variable by an automatic (and hence uninitialized) one.
>
> Also drop the variable introduced by that
On Thu, 2015-06-11 at 07:25 -0400, Julien Grall wrote:
> Hi Ian,
>
> On 11/06/2015 04:56, Ian Campbell wrote:
> > On Wed, 2015-06-10 at 15:21 -0400, Julien Grall wrote:
> >> Hi,
> >>
> >> On 10/06/2015 08:45, Ian Campbell wrote:
> 4. DomU access / assignment PCI device
>
On Thu, 2015-06-11 at 10:40 +0100, Ian Campbell wrote:
> 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)
Here is the log.
(12:02:38) ijc: VK: So, are you happy that the design doc is something which
could be
On Thu, 2015-06-11 at 11:05 +0200, Roger Pau Monné wrote:
> El 10/06/15 a les 21.21, Julien Grall ha escrit:
> >> If there is a reason for this restriction/trade off then it should be
> >> spelled out as part of the design document, as should other such design
> >> decisions (which would include ex
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 determining which translation was in use when a gpa
>>> On 11.06.15 at 13:35, wrote:
> On Thu, 2015-06-11 at 12:20 +0100, Andrew Cooper wrote:
>> As part of the tidyup, we should choose a particular C standard (89,
>> probably) and ensure that the API/ABI complies with `gcc -std=c$VER
>> -pedantic`. This will help to provide a consistent API on ot
Set the EFI framebuffer to write-combining by default. This makes
booting somewhat faster, but more importantly avoids tripping the
watchdog. In particular, before on my test machine, each frame redraw
would take around 80ms, which can trip the 5s watchdog when constructing
dom0, since it outputs s
flight 58369 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58369/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail REGR.
vs. 57474
Regres
On Thu, 2015-06-11 at 13:06 +0100, Jan Beulich wrote:
> >>> On 11.06.15 at 13:35, wrote:
> > On Thu, 2015-06-11 at 12:20 +0100, Andrew Cooper wrote:
> >> As part of the tidyup, we should choose a particular C standard (89,
> >> probably) and ensure that the API/ABI complies with `gcc -std=c$VER
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2015-4164 / XSA-136
version 3
vulnerability in the iret hypercall handler
UPDATES IN VERSION 3
Public release.
Added email header syntax to patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2015-4163 / XSA-134
version 3
GNTTABOP_swap_grant_ref operation misbehavior
UPDATES IN VERSION 3
Public release.
Added email header syntax to patc
trying to shutdown the host when a cpupool exists, has
pCPUs, and has a scheduler different than the Xen's default
one, produces this:
root@Zhaman:~# xl cpupool-cpu-remove Pool-0 8
root@Zhaman:~# xl cpupool-create name=\"Pool-1\" sched=\"credit2\"
Using config file "command line"
cpupool name:
>>> On 11.06.15 at 14:09, wrote:
> Set the EFI framebuffer to write-combining by default. This makes
> booting somewhat faster, but more importantly avoids tripping the
> watchdog. In particular, before on my test machine, each frame redraw
> would take around 80ms, which can trip the 5s watchdog
Hi Julien,
On Thu, Jun 11, 2015 at 07:47:11AM -0400, Julien Grall wrote:
> Hi Chen,
>
> On 11/06/2015 07:16, Chen Baozi wrote:
> >On Thu, Jun 11, 2015 at 10:37:05AM +0100, Ian Campbell wrote:
> >>On Thu, 2015-06-11 at 17:20 +0800, Chen Baozi wrote:
> >>>On Fri, Jun 05, 2015 at 05:22:56PM +0100, I
On 06/11/2015 02:31 PM, Dario Faggioli wrote:
trying to shutdown the host when a cpupool exists, has
pCPUs, and has a scheduler different than the Xen's default
one, produces this:
root@Zhaman:~# xl cpupool-cpu-remove Pool-0 8
root@Zhaman:~# xl cpupool-create name=\"Pool-1\" sched=\"credit2\
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 boot Xen/Dom0
Righto. Looking at t
On 06/11/2015 07:14 PM, Wen Congyang wrote:
On 06/11/2015 06:20 PM, Paul Durrant wrote:
-Original Message-
From: Wen Congyang [mailto:we...@cn.fujitsu.com]
Sent: 11 June 2015 09:48
To: Paul Durrant; Andrew Cooper; Yang Hongyang; xen-devel@lists.xen.org
Cc: Wei Liu; Ian Campbell; guijia
On 06/11/2015 06:20 PM, Paul Durrant wrote:
-Original Message-
From: Wen Congyang [mailto:we...@cn.fujitsu.com]
Sent: 11 June 2015 09:48
To: Paul Durrant; Andrew Cooper; Yang Hongyang; xen-devel@lists.xen.org
Cc: Wei Liu; Ian Campbell; guijianf...@cn.fujitsu.com;
[...]
In our imple
On 06/11/2015 01:35 PM, Jan Beulich wrote:
On 11.06.15 at 14:09, wrote:
Set the EFI framebuffer to write-combining by default. This makes
booting somewhat faster, but more importantly avoids tripping the
watchdog. In particular, before on my test machine, each frame redraw
would take around 80m
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
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
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. For GICv2 that has no affinity
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
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
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
- Also make the code for PSC
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
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. So the domain_max_vcpus should return
the value according to the vGIC the domain uses.
We didn't keep it as the old
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
---
x
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
---
xen/arch/x86/domain_build.c | 6 ++
1 file changed, 6 insertions(+)
di
On 11/06/15 14:03, Ross Lagerwall wrote:
> 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
Reviewed-by: Andrew Cooper
> -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.ji...@intel.com; Eddie Dong; rshri...@cs.ubc.ca; I
Hi,
On 02/06/2015 06:30, Jan Beulich wrote:
On 29.05.15 at 18:32, wrote:
On Wed, 2015-05-27 at 17:04 +0100, Ian Campbell wrote:
Looking at the netback side though it seems like netback_remove is
switching to state=Closed _before_ it calls kobject_uevent(...,
KOBJ_OFFLINE) and it is this which
flight 58380 qemu-upstream-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58380/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-libvirt 11 guest-start fail like 57825
test-amd64-amd64
>>> On 11.06.15 at 15:03, wrote:
> On 06/11/2015 01:35 PM, Jan Beulich wrote:
> On 11.06.15 at 14:09, wrote:
>>> Both Linux and FreeBSD map the EFI framebuffer as write-combining by
>>> default, so I assume (hope) that this is a safe change to make.
>>
>> No, an unaware Dom0 OS may not work c
Hi Parth,
On 17/05/2015 16:04, Parth Dixit wrote:
+#ifdef CONFIG_ACPI
+static char __initdata acpi_param[10] = "";
+static void __init parse_acpi_param(char *s)
+{
+/* Save the parameter so it can be propagated to domain0. */
+safe_strcpy(acpi_param, s);
This acpi_param is never used w
Hi Wei,
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/cpufreq.h
@@ -34,6 +34,12 @@ struct acpi_cpufreq_data {
exte
Hi,
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
pointer when you power down the system.
Signed-off-
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 = set_identity_p2m
Hi,
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?
+gov_num = INTEL_PSTATE_INTERNAL_GOV_NUM;
Why not using cpufreq_governor_list?
+else
+{
+list_f
At 07:41 + on 05 Jun (1433490064), Li, Liang Z wrote:
> > -Original Message-
> > From: Tim Deegan [mailto:t...@xen.org]
> > At 05:06 +0800 on 03 Jun (1433307971), Liang Li wrote:
> > > If the host EPT entry is changed, the nested EPT should be updated.
> > > The current code does not do
>>> 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
inside the ELF parser, namely due
On 06/11/2015 01:31 PM, Dario Faggioli wrote:
> trying to shutdown the host when a cpupool exists, has
> pCPUs, and has a scheduler different than the Xen's default
> one, produces this:
>
> root@Zhaman:~# xl cpupool-cpu-remove Pool-0 8
> root@Zhaman:~# xl cpupool-create name=\"Pool-1\" sched=\"
On 06/11/2015 12:03 PM, Julien Grall wrote:
>
>
> On 11/06/2015 02:12, Olaf Hering wrote:
>> On Wed, Jun 10, Julien Grall wrote:
>>
>>> There is also a variable MAX_CPUS defined to 256. which is used every.
>>
>> You are right, while forwarding an old patch (from memory) I changed the
>> wrong pl
Hi Chen,
On 11/06/2015 09:05, 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, which
holds the affinit
On 06/11/2015 04:17 AM, Tian, Kevin wrote:
From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
switch ( vendor )
{
case X86_VENDOR_AMD:
-ret = svm_vpmu_initialise(v, opt_vpmu_enabled);
+ret = svm_vpmu_initialise(v);
break;
case X86_VENDO
On 06/10/2015 05:20 AM, Chunyan Liu wrote:
Add pvusb APIs, including:
- attach/detach (create/destroy) virtual usb controller.
- attach/detach usb device
- list usb controller and usb devices
- some other helper functions
Signed-off-by: Chunyan Liu
Signed-off-by: Simon Cao
I've teste
>>> On 11.06.15 at 16:54, wrote:
> On 06/11/2015 04:17 AM, Tian, Kevin wrote:
>>> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
>
>>> switch ( vendor )
>>> {
>>> case X86_VENDOR_AMD:
>>> -ret = svm_vpmu_initialise(v, opt_vpmu_enabled);
>>> +ret = svm_
On 06/11/2015 11:04 AM, Jan Beulich wrote:
On 11.06.15 at 16:54, wrote:
On 06/11/2015 04:17 AM, Tian, Kevin wrote:
From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
switch ( vendor )
{
case X86_VENDOR_AMD:
-ret = svm_vpmu_initialise(v, opt_vpmu_enabled);
+
Pang, LongtaoX writes ("RE: [OSSTEST Nested PATCH v11 5/7] Add new script to
customize nested test configuration"):
> [Ian Jackson [mailto:ian.jack...@eu.citrix.com]]
> > longtao.pang writes ("[OSSTEST Nested PATCH v11 5/7] Add new script to
> > > +target_cmd_root($l1, "update-rc.d osstest-confirm
Pang, LongtaoX writes ("RE: [OSSTEST Nested PATCH v11 7/7] Add test job for
nest test case"):
...
> > * Why do you specify the l2 disk size explicitly ?
>
> Just for some configure rule in our lab, we assign at least '15000M' disk
> size for nested L2 guest,
I see. What's the reasoning behin
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.
> >
> I have noticed the logs which printed on screen during job ru
Wei Liu writes ("[PATCH OSSTEST v4 1/2] TestSupport: introduce
guest_var_boolean"):
> Signed-off-by: Wei Liu
...
> +sub guest_var_boolean ($$) {
> +my ($gho, $runvartail) = @_;
> +return guest_var($gho, $runvartail, 'false') =~ m/true/;
> +}
Acked-by: Ian Jackson
__
Hi Chen,
On 11/06/2015 09:05, Chen Baozi wrote:
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
Pang, LongtaoX writes ("RE: [OSSTEST Nested PATCH v11 4/7] Changes on test step
of Debian hvm guest install"):
> [Ian Jackson:]
> > longtao.pang writes ("[OSSTEST Nested PATCH v11 4/7] Changes on test step of
> > > +# Use guest_var to get specific disk size, or will use default
> > > $disk_mb
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
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
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 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
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
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.
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/
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
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
...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 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 +
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
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
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
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-
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
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
101 - 200 of 281 matches
Mail list logo
