On 03/28/2015 05:12 AM, Andrew Cooper wrote:
On 27/03/15 02:35, Kai Huang wrote:
It's possible domain has already been in log-dirty mode when creating vcpu, in
which case we should enable PML for this vcpu if PML has been enabled for the
domain.
Signed-off-by: Kai Huang
---
xen/arch/x86/hv
branch xen-unstable
xen branch xen-unstable
job test-amd64-amd64-xl
test guest-localmigrate
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbit
On Sun, 2015-03-29 at 16:26 +0100, xen.org wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-amd64-xl-credit2
> test guest-localmigrate
>
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu gi
On Fri, 2015-03-27 at 21:17 +, Andrew Cooper wrote:
> > -int xc_domain_maximum_gpfn(xc_interface *xch, domid_t domid, xen_pfn_t
> > *gpfns);
> > +int xc_domain_maximum_gpfn(xc_interface *xch, domid_t domid);
>
> It is perfectly fine for xc_domain_maximum_gpfn() to keep its *gpfn
> pointer, as
On Wed, 2015-02-11 at 09:46 +0800, Hongyang Yang wrote:
>
> 在 02/11/2015 04:09 AM, Ian Jackson 写道:
> > * Add two comments in libxl_remus_disk_drbd documenting buggy handling
> >of the hotplug script exit status.
> >
> > * Add a section heading for async exec in libxl_aoutils.c
> >
> > * Mentio
On Fri, 2015-03-27 at 10:29 +, Olaf Hering wrote:
> Without it the actual error message is not written to xenstore.
>
> Signed-off-by: Olaf Hering
> Cc: Ian Jackson
> Cc: Stefano Stabellini
> Cc: Ian Campbell
> Cc: Wei Liu
Acked + applied, thanks.
_
On Wed, 2015-03-25 at 19:37 +, Julien Grall wrote:
> Hi Ian,
>
> On 25/03/15 15:34, Ian Campbell wrote:
> > Signed-off-by: Ian Campbell
>
> Reviewed-by: Julien Grall
Applied, thanks.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lis
On Thu, 2015-03-26 at 12:46 +, George Dunlap wrote:
> No functional changes.
>
> Signed-off-by: George Dunlap
Although the series as a whole is RFC I can't see any reason to hold
back on this particular improvement, so Acked + applied.
___
Xen-d
On Mon, 2015-03-30 at 09:28 +0800, Chen, Tiejun wrote:
> Sounds it should be a legacy fix to qemu-xen-tranditional :) So lets do
> it now,
>
> @@ -326,6 +326,10 @@ static char **
> libxl__build_device_model_args_old(libxl__gc *gc,
> }
> if (libxl_defbool_val(b_info->u.hvm.gfx
On Fri, 2015-03-27 at 14:53 -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 27, 2015 at 06:44:52PM +, Andrew Cooper wrote:
> > Introduced by c/s 1781f00e
> >
> > Signed-off-by: Andrew Cooper
> > Coverity-IDs: 1291939 (stray semicolon), 1291941 (structually dead code)
> > CC: Konrad Rzeszute
On Thu, 2015-03-26 at 14:08 -0400, Boris Ostrovsky wrote:
> Commit ba59e2ce935d ("libxc: allocate memory with vNUMA information for
> PV guest") creates default vNUMA layout with a single range containing
> all memory. The end of the range is calculated by shifting
> dom->total_pages by 12 to the l
On Thu, 2015-03-26 at 11:58 +, Julien Grall wrote:
> Hi Ian,
>
> On 26/03/2015 10:54, Ian Campbell wrote:
> > The 64-bit ABI is different to 32-bit:
> >
> > - uses x16 as the op register rather than r12.
> > - arguments in x0..x5 and not r0..r5. Using rN here potentially
> > truncates.
On Wed, 2015-03-25 at 14:01 +, George Dunlap wrote:
> Reviewed-by: George Dunlap
> Tested-by: George Dunlap
Applied, thanks.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 30/03/15 07:11, Kai Huang wrote:
>
>
> On 03/28/2015 04:38 AM, Andrew Cooper wrote:
>> On 27/03/15 02:35, Kai Huang wrote:
>>> PML requires A/D bit support so enable it for further use.
>>>
>>> Signed-off-by: Kai Huang
>>> ---
>>> xen/arch/x86/hvm/vmx/vmcs.c| 1 +
>>> xen/arch/x86/mm
On Fri, 2015-03-27 at 22:18 +, Tamas K Lengyel wrote:
>
> >union hsr hsr)
> > {
> > -register_t addr = READ_SYSREG(FAR_EL2);
> > -inject_iabt_exception(regs, addr, hsr.len);
> > +struct hsr_ia
On Thursday 26 February 2015 12:22 AM, Julien Grall wrote:
Currently, Xen is supporting PCI and Platform device (based on Device Tree).
While Xen only supports Platform device on ARM, Xen will gain support of
PCI soon.
Some drivers, such as IOMMU drivers, may handle PCI and platform device in
On 30/03/15 07:43, Kai Huang wrote:
>
>
> On 03/28/2015 05:09 AM, Andrew Cooper wrote:
>> On 27/03/15 02:35, Kai Huang wrote:
>>
>>> +}
>>> +
>>> +int vmx_vcpu_enable_pml(struct vcpu *v)
>>> +{
>>> +struct domain *d = v->domain;
>>> +
>>> +ASSERT(!vmx_vcpu_pml_enabled(v));
>>> +
>>> +v-
On 02/25/2015 05:00 PM, Juergen Gross wrote:
On 02/25/2015 03:24 PM, David Vrabel wrote:
On 24/02/15 06:27, Juergen Gross wrote:
On 02/19/2015 07:07 PM, David Vrabel wrote:
On 18/02/2015 06:51, Juergen Gross wrote:
+{
+unsigned long pfn;
+unsigned long area_start, area_end;
+unsig
On 30/03/15 08:03, Kai Huang wrote:
>
>
> On 03/28/2015 05:12 AM, Andrew Cooper wrote:
>> On 27/03/15 02:35, Kai Huang wrote:
>>> It's possible domain has already been in log-dirty mode when
>>> creating vcpu, in
>>> which case we should enable PML for this vcpu if PML has been
>>> enabled for the
On 25/03/15 16:39, Jan Beulich wrote:
> When a device gets detached from a guest, pciback will clear its
> command register, thus disabling both memory and I/O decoding. The
> disabled memory decoding, however, has an effect on the MSI-X table
> accesses the hypervisor does: These won't have the in
On 30/03/15 03:11, Wu, Feng wrote:
>
>> -Original Message-
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: Friday, March 27, 2015 9:49 PM
>> To: Wu, Feng; xen-devel@lists.xen.org
>> Cc: Zhang, Yang Z; Tian, Kevin; k...@xen.org; jbeul...@suse.com
>> Subject: Re: [Xen-devel
On Thu, 2015-03-26 at 17:07 +, Jan Beulich wrote:
> having been released mid January, it is time to get ready for 4.5.1-rc1.
> Please reply with backport requests which you consider necessary but
> still missing. Please also be patient with them being pulled in - I'll be
> gone the coming two w
On Thu, 2015-03-26 at 16:20 +0100, Roger Pau Monné wrote:
> El 16/03/15 a les 14.29, Ross Lagerwall ha escrit:
> > From: Andrew Cooper
> >
> > POLLHUP|POLLIN is a valid revent to receive when there is readable data in a
> > pipe, but the writable fd has been closed. This occurs in migration v2 w
On 28/03/15 20:10, Sander Eikelenboom wrote:
> Saturday, March 28, 2015, 6:30:39 PM, you wrote:
>
>> On 28/03/15 15:34, Sander Eikelenboom wrote:
>>> Hi Jan,
>>>
>>> Commit 1aeb1156fa43fe2cd2b5003995b20466cd19a622:
>>> "x86 don't change affinity with interrupt unmasked",
>>> gives trouble on my AMD
On Wednesday 25 March 2015 11:05 PM, Stefano Stabellini wrote:
On Wed, 25 Mar 2015, Manish Jaggi wrote:
On Tuesday 24 March 2015 07:34 PM, Robert VanVossen wrote:
On 3/24/2015 7:07 AM, Manish Jaggi wrote:
On Monday 23 March 2015 07:16 PM, Robbie VanVossen wrote:
If multiple devices are being
Using !usr_mode(regs) only catches arm32 usr mode and not arm64 user
mode, switch to psr_mode_is_user instead.
Signed-off-by: Ian Campbell
Reviewed-by: Julien Grall
---
v4: New patch
---
xen/arch/arm/traps.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/tra
By adding GUEST_BUG_ON locally to traps.c.
Signed-off-by: Ian Campbell
Reviewed-by: Julien Grall
---
v4: This is now only used for HSR decode and no in the individual do_*
which instead inject undef.
v3: New patch
---
xen/arch/arm/traps.c | 44 ++--
This embodies the logic on arm64 that userspace can be either 32-bit
or 64-bit. It will be used in other places shortly.
Note that the logic differs slightly because the original (in
inject_abt64_exception) knew that the kernel was 64-bit and could
therefore assume that any 32-bit mode was userspa
We do not set HCR_EL2.TSW so we will never see these.
This is undoubtedly wrong, but for now remove the dead code.
However, retain the HSR_SYSREG_* added by the precursor to this patch,
although they aren't used they are factually accurate and may as well
be kept for future use.
Signed-off-by: I
Fix a coding style issue while in the area.
Signed-off-by: Ian Campbell
Reviewed-by: Julien Grall
---
xen/arch/arm/traps.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 37bc150..e13b959 100644
--- a/xen/arch/arm/
XSA-102/CVE-2014-5147[0] concerned a crash when trapping from 32-bit
userspace in a 64-bit guest. Part of that security patch was c0020e09970
"xen: arm: Handle traps from 32-bit userspace on 64-bit kernel as undef
fix" which turned the exploitable crash into a #undef to the guest (so
as to kill the
Accesses to these from 32-bit userspace would cause a hypervisor
exception (host crash) when running a 64-bit kernel, which is worked
around by the fix to XSA-102. On 32-bit kernels they would be
implemented as RAZ/WI which is incorrect but harmless.
Update as follows:
- DBGDSCRINT should be R/O.
They are trapped only with HCR_EL2.TID2 which we don't set, and in any
case we handled only for 32-bit.
One day we may want to trap and emulate these, but for now don't
bother with the dead code.
Signed-off-by: Ian Campbell
Reviewed-by: Julien Grall
---
v4: New patch
---
xen/arch/arm/traps.c
CP14 dbg and general CP register access are both handled with
unconditional injection of #undef from their respective handlers, so
allow these even from 32-bit userspace on a 64-bit kernel.
SMC32 and HVC32 should only come from a guest in AArch32 mode and
SMC64 and HVC64 should only come from a gu
Rather than using the v8 register names and the v7 bit names, which
makes things needlessly difficult when reading.
Signed-off-by: Ian Campbell
Reviewed-by: Julien Grall
---
v3: New patch.
---
xen/arch/arm/time.c |2 +-
xen/include/asm-arm/processor.h |4 ++--
2 files change
Previously userspace access to PM* would have been incorrectly (but
benignly) implemented as RAZ/WI when running on a 32-bit kernel and
would cause a hypervisor exception (host crash) when running a 64-bit
kernel (this was already solved via the fix to XSA-102).
PMINTENSET, PMINTENCLR are EL1 only
p15,0,c9,c13,1 is PMXEVTYPER not PMXEVCNTR.
p15,0,c9,c13,2 is PMXEVCNTR not PMXEVCNR.
Signed-off-by: Ian Campbell
Reviewed-by: Julien Grall
---
xen/arch/arm/traps.c |2 +-
xen/include/asm-arm/cpregs.h |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/ar
This removes the unconditional #undef injected in response to such
traps which was added by the fixes to CVE-2014-5147 / XSA-102 in
c0020e099702 "xen: arm: Handle traps from 32-bit userspace on 64-bit
kernel as undef", we now handle such traps correctly.
Signed-off-by: Ian Campbell
Reviewed-by: J
All OSes we have run on top of Xen use CNTP_TVAL_EL0 but for
completeness we really should handle CVAL too.
In vtimer_emulate_cp64 pull the propagation of the 64-bit result into
two 32-bit registers out of the switch to avoid duplicating for every
register. We also need to initialise x now since p
Previously 32-bit userspace on 32-bit kernel and 64-bit userspace on
64-bit kernel could access these registers irrespective of whether the
kernel had configured them to be allowed to. To fix this:
- Userspace access to CNTP_CTL_EL0 and CNTP_TVAL_EL0 should be gated
on CNTKCTL_EL1.EL0PTEN.
-
Previously we implemented all registers as RAZ/WI even if they
shouldn't be accessible to userspace.
It is not entirely clear whether attempts to access *_EL1 registers
from EL0 will trap to EL1 or EL2, be conservative and treat as an
undef injection.
PMUSERENR_EL0 and MDCCSR_EL0 are R/O to EL0.
Hello,
On 30/03/15 12:04, Manish Jaggi wrote:
>>> Julien/Ian could you please hold the merge of this patch.
>> Sorry Manish, but the Xen community works on a first come first served
>> basis: if/when this patch is considered in good condition and ready to
>> be merged, is likely to be merged.
>>
Hi Ian,
On 30/03/15 11:24, Ian Campbell wrote:
> On Thu, 2015-03-26 at 17:07 +, Jan Beulich wrote:
>> having been released mid January, it is time to get ready for 4.5.1-rc1.
>> Please reply with backport requests which you consider necessary but
>> still missing. Please also be patient with t
Just last week I was running staging to test pvscsi on this HP ProBook
6555b, since around Wednesday I think. But todays staging fails to boot.
So I started a bisect in xen/, but every attempt to boot xen.gz results
in a hang at the same place. Even going back to the state of 4.5.0.
Any idea what
Hi Ian,
On 27/03/15 17:05, Ian Campbell wrote:
> On Fri, 2015-03-27 at 16:36 +, Julien Grall wrote:
>> Hi Ian,
>>
>> On 27/03/15 14:33, Ian Campbell wrote:
>>> We set HCR_EL2.TSW but only (sort of) handle 32-bit access to DCCISW
>>> but not the other two registers, nor any 64-bit access. Add h
On 30/03/15 13:14, Olaf Hering wrote:
> Just last week I was running staging to test pvscsi on this HP ProBook
> 6555b, since around Wednesday I think. But todays staging fails to boot.
> So I started a bisect in xen/, but every attempt to boot xen.gz results
> in a hang at the same place. Even goi
Hi Ian,
On 30/03/15 12:12, Ian Campbell wrote:
> We do not set HCR_EL2.TSW so we will never see these.
>
> This is undoubtedly wrong, but for now remove the dead code.
Would it be better to trap and ignore them?
Even though it wouldn't be entirely correct, it would be better than
letting the gu
For QEMU traditional stubdom, this is incompatible startup protocol
change. This change needs to work with corresponding libxl changeset.
QEMU traditional is shipped with Xen so we are allowed to do such
change.
For QEMU traditional running in Dom0, there is no functional change
because it will s
No functional change introduced.
Signed-off-by: Wei Liu
---
hw/xen_console.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/hw/xen_console.c b/hw/xen_console.c
index 80beb31..ef6dfab 100644
--- a/hw/xen_console.c
+++ b/hw/xen_console.c
@@ -201,13 +201,13 @@ st
On 30/03/15 13:37, Wei Liu wrote:
> For QEMU traditional stubdom, this is incompatible startup protocol
> change. This change needs to work with corresponding libxl changeset.
> QEMU traditional is shipped with Xen so we are allowed to do such
> change.
>
> For QEMU traditional running in Dom0, th
On Thu, Mar 26, 2015 at 05:07:26PM +, Jan Beulich wrote:
> All,
>
> having been released mid January, it is time to get ready for 4.5.1-rc1.
> Please reply with backport requests which you consider necessary but
> still missing. Please also be patient with them being pulled in - I'll be
> gone
On Mon, 2015-03-30 at 13:28 +0100, Julien Grall wrote:
> Hi Ian,
>
> On 30/03/15 12:12, Ian Campbell wrote:
> > We do not set HCR_EL2.TSW so we will never see these.
> >
> > This is undoubtedly wrong, but for now remove the dead code.
>
> Would it be better to trap and ignore them?
Yes, but thi
El 26/03/15 a les 18.07, Jan Beulich ha escrit:
> All,
>
> having been released mid January, it is time to get ready for 4.5.1-rc1.
> Please reply with backport requests which you consider necessary but
> still missing. Please also be patient with them being pulled in - I'll be
> gone the coming t
Monday, March 30, 2015, 1:04:26 PM, you wrote:
> On 28/03/15 20:10, Sander Eikelenboom wrote:
>> Saturday, March 28, 2015, 6:30:39 PM, you wrote:
>>
>>> On 28/03/15 15:34, Sander Eikelenboom wrote:
Hi Jan,
Commit 1aeb1156fa43fe2cd2b5003995b20466cd19a622:
"x86 don't change affi
create <5515870c.1080...@linaro.org>
title it proper handling of set/way cache maintenance instructions by guests on
ARM
thanks
On Mon, 2015-03-30 at 13:17 +0100, Julien Grall wrote:
> Would it be worth to open a bug on the tracker and mark as a blocker?
Yes, done.
Ian.
__
On 03/17/2015 03:33 PM, Dario Faggioli wrote:
> such as it is taken care of by the various schedulers, rather
> than happening in schedule.c. In fact, it is the schedulers
> that know better which locks are necessary for the specific
> dumping operations.
>
> While there, fix a few style issues (i
On Mon, Mar 30, 2015 at 5:36 PM, Andrew Cooper
wrote:
> On 30/03/15 07:11, Kai Huang wrote:
>>
>>
>> On 03/28/2015 04:38 AM, Andrew Cooper wrote:
>>> On 27/03/15 02:35, Kai Huang wrote:
PML requires A/D bit support so enable it for further use.
Signed-off-by: Kai Huang
---
>>>
On 30/03/15 14:35, Kai Huang wrote:
> On Mon, Mar 30, 2015 at 5:36 PM, Andrew Cooper
> wrote:
>> On 30/03/15 07:11, Kai Huang wrote:
>>>
>>> On 03/28/2015 04:38 AM, Andrew Cooper wrote:
On 27/03/15 02:35, Kai Huang wrote:
> PML requires A/D bit support so enable it for further use.
>
On Mon, Mar 30, 2015 at 5:54 PM, Andrew Cooper
wrote:
> On 30/03/15 07:43, Kai Huang wrote:
>>
>>
>> On 03/28/2015 05:09 AM, Andrew Cooper wrote:
>>> On 27/03/15 02:35, Kai Huang wrote:
>>>
+}
+
+int vmx_vcpu_enable_pml(struct vcpu *v)
+{
+struct domain *d = v->domain;
Processing commands for x...@bugs.xenproject.org:
> create <5515870c.1080...@linaro.org>
Created new bug #50 rooted at `<5515870c.1080...@linaro.org>'
Title: `Re: [Xen-devel] [PATCH v4 08/15] xen: arm: don't pretend to handle
cache maintenance by set/way'
> title it proper handling of set/way cac
flight 50257 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/50257/
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. 36511
build-i386-libvir
On Thu, Mar 26, 2015 at 03:08:58PM +, Jonathan Davies wrote:
>
> On 26/03/15 12:05, Eric Dumazet wrote:
> >On Thu, 2015-03-26 at 11:13 +, Jonathan Davies wrote:
> >>xen-netfront limits transmitted skbs to be at most 44 segments in size.
> >>However,
> >>GSO permits up to 65536 bytes, whic
On 03/17/2015 03:33 PM, Dario Faggioli wrote:
> In fact, printing the cpupool's CPU online mask
> for each vCPU is just redundant, as that is the
> same for all the vCPUs of all the domains in the
> same cpupool, while hard affinity is already part
> of the output of dumping domains info.
>
> Inst
On Wed, Mar 25, 2015 at 02:08:33PM -0600, Jim Fehlig wrote:
> This small series of patches fixes some issues wrt domain destroy in
> the libxl driver. The primary motivation for this work is to
> prevent locking the virDomainObj during long running destroy operations
> on large memory domains.
>
On 30/03/15 14:15, Ian Campbell wrote:
> On Mon, 2015-03-30 at 13:28 +0100, Julien Grall wrote:
>> Hi Ian,
>>
>> On 30/03/15 12:12, Ian Campbell wrote:
>>> We do not set HCR_EL2.TSW so we will never see these.
>>>
>>> This is undoubtedly wrong, but for now remove the dead code.
>>
>> Would it be be
Hi
When there is a page fault the trapper of the page fault in the
hypervisor is do_page_fault in xen/arch/x86/traps.c right?
in this funcion i found a method read_cr2() which return the virtual
adrress of the page who generate the page fault.
My question is : is it possible to get the machine a
Hi,
On 30/03/15 14:15, Roger Pau Monné wrote:
> El 26/03/15 a les 18.07, Jan Beulich ha escrit:
>> All,
>>
>> having been released mid January, it is time to get ready for 4.5.1-rc1.
>> Please reply with backport requests which you consider necessary but
>> still missing. Please also be patient wi
flight 50256 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/50256/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt5 libvirt-build fail REGR. vs. 36527
build-amd64-libvi
It is number of vmexits and a moderate quantity of qemu logging which can
safely be avoided when not specifically debugging a PCI hotplug issue.
As mk_dsdt is a build system tool, pass 'debug' as a command line parameter
rather than "hardcoding" it via the compilation of mk_dsdt itself.
Signed-of
On Thu, Mar 26, 2015 at 04:23:19PM +, Tim Deegan wrote:
> Hi,
>
> After XSA-109 (a null function-pointer dereference) we've been
> thinking about things we can do to make null pointers less dangerous
> in PV guests. This is a problem for pure PV only - when Xen is
> running HVM and PVH guests
Hi Julien,
On Fri, Mar 20, 2015 at 10:14 PM, Julien Grall wrote:
> Hello Vijay,
>
> On 19/03/2015 14:37, vijay.kil...@gmail.com wrote:
>>
>> diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
>> index 435dfcd..f091739 100644
>> --- a/xen/include/asm-arm/irq.h
>> +++ b/xen/include/
On Thu, Mar 26, 2015 at 12:46:08PM +, George Dunlap wrote:
> Download and build XenServer's blktap as an external tree, similar to
> qemu-xen.
>
> As of this patch we just download and build it, but don't install or
> use it.
>
> Signed-off-by: George Dunlap
> ---
>
> FIXME: Directly use th
On Mon, 2015-03-30 at 15:33 +0100, Wei Liu wrote:
> On Thu, Mar 26, 2015 at 12:46:08PM +, George Dunlap wrote:
> > Download and build XenServer's blktap as an external tree, similar to
> > qemu-xen.
> >
> > As of this patch we just download and build it, but don't install or
> > use it.
> >
>
On 03/30/2015 03:33 PM, Wei Liu wrote:
> On Thu, Mar 26, 2015 at 12:46:08PM +, George Dunlap wrote:
>> Download and build XenServer's blktap as an external tree, similar to
>> qemu-xen.
>>
>> As of this patch we just download and build it, but don't install or
>> use it.
>>
>> Signed-off-by: Ge
On 03/30/2015 03:41 PM, Ian Campbell wrote:
> On Mon, 2015-03-30 at 15:33 +0100, Wei Liu wrote:
>> On Thu, Mar 26, 2015 at 12:46:08PM +, George Dunlap wrote:
>>> Download and build XenServer's blktap as an external tree, similar to
>>> qemu-xen.
>>>
>>> As of this patch we just download and bui
The commit a8f8a590e02d2d2b717257c0bd9a8b396103bdf4
"libxc: Check xc_domain_maximum_gpfn for negative return values"
introduced an regression in tools outside libxc (migrate v2)
which wanted the unfiltered GPFN value. Said commit added
a wrapper which added +1 if there were no errors.
To make it w
On Thu, Mar 26, 2015 at 08:38:24PM +0800, Chao Peng wrote:
> Introduce a util function libxl_count_physical_sockets() to get physical
> socket count. Replaced CMT code with the new function in xl.
>
> Signed-off-by: Chao Peng
> ---
> tools/libxl/libxl_utils.c | 17 +
> tools/libx
On 30/03/15 15:41, Ian Campbell wrote:
> On Mon, 2015-03-30 at 15:33 +0100, Wei Liu wrote:
>> On Thu, Mar 26, 2015 at 12:46:08PM +, George Dunlap wrote:
>>> Download and build XenServer's blktap as an external tree, similar to
>>> qemu-xen.
>>>
>>> As of this patch we just download and build it
On 30/03/15 15:46, Konrad Rzeszutek Wilk wrote:
> The commit a8f8a590e02d2d2b717257c0bd9a8b396103bdf4
> "libxc: Check xc_domain_maximum_gpfn for negative return values"
> introduced an regression in tools outside libxc (migrate v2)
> which wanted the unfiltered GPFN value. Said commit added
> a wra
Signed-off-by: Andrew Cooper
CC: Keir Fraser
CC: Jan Beulich
---
xen/arch/x86/x86_64/traps.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
index f58e3d6..fc35aba 100644
--- a/xen/arch/x86/x86_64/traps.c
+++
Hi Julien,
On Tue, Mar 24, 2015 at 5:18 PM, Julien Grall wrote:
> Hello Vijay,
>
> More questions/remarks about command processing.
>
> On 19/03/2015 14:38, vijay.kil...@gmail.com wrote:
>>
>> +int vgic_its_process_cmd(struct vcpu *v, struct vgic_its *vits)
>> +{
>> +struct its_cmd_block virt
On Mon, Mar 30, 2015 at 11:41 AM, Ian Campbell
wrote:
> On Fri, 2015-03-27 at 22:18 +, Tamas K Lengyel wrote:
>
> >
> > >union hsr hsr)
> > > {
> > > -register_t addr = READ_SYSREG(FAR_EL2);
> > > -inject_iabt_ex
On Tue, Mar 24, 2015 at 04:59:47PM +, Ian Campbell wrote:
[...]
> > for running xentop in batch mode where the output can be captured. For
> > normal screen viewing, I doubt anyone has a screen with more that 1024
> > lines on which to view the output :)
>
> :-). I'm not sure if there is anyon
On Mon, Mar 30, 2015 at 03:20:19PM +0100, Andrew Cooper wrote:
> It is number of vmexits and a moderate quantity of qemu logging which can
> safely be avoided when not specifically debugging a PCI hotplug issue.
Could we just make qemu-X not include this data when the we
run in production? And in
On Mon, 2015-03-30 at 17:14 +0200, Tamas K Lengyel wrote:
> According to ARMv8 ARM HPFAR is valid for any of these:
> * A Translation or Access Flag fault on a stage 2 translation.
> * A stage 2 Address Size fault.
> * A fault on the stage 2 transl
The check is superflous. If the 'max_vcpus' (argument
value) is greater than pCPU and --ignore-host has not
been supplied we would print an warning and return
and not call this code.
If the --ignore-host parameter had been used we would
never end up in this condition and enforce 'max_vcpus'.
The
And use that for all of its callers in the tree.
Signed-off-by: Konrad Rzeszutek Wilk
Acked-by: Ian Campbell
---
tools/libxl/libxl.c | 19 +++
tools/libxl/libxl.h | 9 -
tools/libxl/libxl_types.idl | 1 +
tools/libxl/xl_cmdimpl.c| 4 ++--
4 files c
The function does not return any values at all. Convert the
internal libxl errors (ERROR_FAIL, ..., etc) to 1.
Signed-off-by: Konrad Rzeszutek Wilk
Acked-by: Ian Campbell
---
tools/libxl/xl_cmdimpl.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/tools/lib
There is no sense in trying to online (or offline) CPUs when the size of
cpumap is greater than the maximum number of VCPUs the guest can go to.
As such fail the operation if the count of CPUs to online is greater
than what the guest started with. For the offline case we do not
check (as the bits
Instead of just printing an generic error.
Signed-off-by: Konrad Rzeszutek Wilk
Acked-by: Ian Campbell
---
tools/libxl/xl_cmdimpl.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 1c07ac6..0ccf257 100644
---
Hey Ian and Ian,
Since v3 [http://lists.xen.org/archives/html/xen-devel/2015-03/msg02822.html]
- Constify the libxl_dominfo and handle libxl_domain_info errors.
- Made libxl_domain_info use logging if domain is gone.
- Drop libxl: Add to libxl__domain_type a new return value
(LIBXL_DOMAIN_TYPE_NO
If we cannot find the domain - log an error (and still
continue returning an error).
Signed-off-by: Konrad Rzeszutek Wilk
---
tools/libxl/libxl.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 13a98fd..22f0f0c 100644
---
We have a check to warn the user if they are overcommitting.
But the check only checks the hosts CPU amount and does
not take into account the case when the user is trying to fix
the overcommit. That is - they want to limit the amount of
online VCPUs.
This fix allows the user to offline vCPUs with
On Mon, Mar 30, 2015 at 5:24 PM, Ian Campbell
wrote:
> On Mon, 2015-03-30 at 17:14 +0200, Tamas K Lengyel wrote:
>
> > According to ARMv8 ARM HPFAR is valid for any of these:
> > * A Translation or Access Flag fault on a stage 2
> translation.
> > * A stage 2 A
On 30/03/15 15:32, Vijay Kilari wrote:
>Stefano suggested to use arch_irq_desc to hold virq and its_device
structure.
> Another question is why another structure irq_guest is created?. Can't we
> reuse
> arch_irq_desc?
Here is the answer I gave to Stefano when I introduced this new structure
On 30/03/15 16:22, Konrad Rzeszutek Wilk wrote:
> On Mon, Mar 30, 2015 at 03:20:19PM +0100, Andrew Cooper wrote:
>> It is number of vmexits and a moderate quantity of qemu logging which can
>> safely be avoided when not specifically debugging a PCI hotplug issue.
> Could we just make qemu-X not inc
flight 50260 linux-3.16 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/50260/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3865 xen-build fail REGR. vs. 34167
build-armhf-libvirt
On Mon, Mar 30, 2015 at 04:30:01PM +0100, Andrew Cooper wrote:
> On 30/03/15 16:22, Konrad Rzeszutek Wilk wrote:
> > On Mon, Mar 30, 2015 at 03:20:19PM +0100, Andrew Cooper wrote:
> >> It is number of vmexits and a moderate quantity of qemu logging which can
> >> safely be avoided when not specific
On 30/03/15 16:02, Vijay Kilari wrote:
> Hi Julien,
Hello Vijay,
> On Tue, Mar 24, 2015 at 5:18 PM, Julien Grall wrote:
>> On 19/03/2015 14:38, vijay.kil...@gmail.com wrote:
>>>
>>> +int vgic_its_process_cmd(struct vcpu *v, struct vgic_its *vits)
>>> +{
>>> +struct its_cmd_block virt_cmd;
>>
On Mon, Mar 30, 2015 at 03:43:07PM +0100, George Dunlap wrote:
> On 03/30/2015 03:33 PM, Wei Liu wrote:
> > On Thu, Mar 26, 2015 at 12:46:08PM +, George Dunlap wrote:
> >> Download and build XenServer's blktap as an external tree, similar to
> >> qemu-xen.
> >>
> >> As of this patch we just dow
1 - 100 of 126 matches
Mail list logo
