Hi all:
Now a days, we tested Redhat 6.2(6.4) on Xen(version 4.1.2).
If we config the cpu number more than 32, it'll show 32 in
the VM, and if we config it 64 cpus, the VM will crash and
the log is list below.
Can someone tell us why is this happening?
thanks
===cras
Hi all,
Today's linux-next merge of the xen-tip tree got a conflict in
drivers/xen/Kconfig between commit 94ccae47e02d ("XEN / ACPI: Make XEN
ACPI depend on X86") from the arm64-acpi tree and commit 628c28eefd6f
("xen: unify foreign GFN map/unmap for auto-xlated physmap guests")
from the xen-tip t
flight 36729 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/36729/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-xsm 9 guest-start fail never pass
test-amd64-amd64-libvirt-xsm 9 guest-start
On 03/25/2015 08:59 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Mar 20, 2015 at 04:17:52PM -0700, Luis R. Rodriguez wrote:
From: "Luis R. Rodriguez"
It is possible to enable CONFIG_MTRR and up with it
disabled at run time and yet CONFIG_X86_PAT continues
to kick through fully functionally. This c
flight 36728 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/36728/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 12 guest-localmigratefail REGR. vs. 36514
test-amd64-amd64-xl
flight 36748 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/36748/
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 Mon, Mar 23, 2015 at 12:20:47PM -0500, Bjorn Helgaas wrote:
> Hi Luis,
>
> This seems OK to me,
Great.
> but I'm curious about a few things.
>
> On Fri, Mar 20, 2015 at 6:17 PM, Luis R. Rodriguez
> wrote:
> > From: "Luis R. Rodriguez"
> >
> > This allows drivers to take advantage of write
If we fail to create the thread we leak the shutdown_info
structure.
Signed-off-by: Konrad Rzeszutek Wilk
---
src/libxl/libxl_domain.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 774b070..0ac5c62 100644
--- a/src
On Wed, Mar 25, 2015 at 02:08:35PM -0600, Jim Fehlig wrote:
> A job should be acquired at the beginning of a domain destroy operation,
> not at the end when cleaning up the domain. Fix two occurances of this
> late job acquisition in the libxl driver. Doing so renders
> libxlDomainCleanup unused,
That seems OK to me. Probably still wrong, but no worse than it was
before.
>>>
>>> Interesting. The mechanism for PCI passthrough can either synthesize
>>> and PCI bus number starting at zero (so first device is always 0:0:0.0)
>>> or it can replicate the backend PCI topology. That mea
On 2015/3/25 18:32, Ian Campbell wrote:
On Wed, 2015-03-25 at 09:10 +0800, Chen, Tiejun wrote:
+But when given as a string the B option describes the type
+of device to enable. Not this behavior is only supported with upstream
"Note" and "the upstream..."
Fixed.
+=item "igd"
+
+Enables
On 2015/3/25 18:26, Ian Campbell wrote:
On Wed, 2015-03-25 at 09:18 +0800, Chen, Tiejun wrote:
Actually my problem is that, I need to add a new parameter, 'flag', like
this, xc_assign_device(xxx,xxx,flag). So if I don't refine xc.c, tools
can't be compiled successfully. Or maybe you're suggestin
flight 36726 qemu-upstream-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/36726/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail REGR. vs. 31663
Tests w
Hi Ian,
On 25/03/2015 15:34, Ian Campbell wrote:
PC only needs adjusting by 2, otherwise we rerun the instruction prior
to the hvc as well.
I don't understand why you have to adjust PC by 2 for thumb.
The spec encodes the HVC thumb instruction on 32 bits (i.e 4 bytes).
Regards,
--
Julien Gr
Hi Ian,
On 25/03/2015 15:34, 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.
- return value goes in x0, not r0.
Hypercalls can only be made directly fr
flight 36723 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/36723/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 26303
Tests which are failin
flight 36722 linux-3.16 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/36722/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 5 kernel-build fail REGR. vs. 34167
test-amd64-i386-pair
Ian Campbell wrote:
> On Mon, 2015-02-09 at 11:09 +, Wei Liu wrote:
>
>> Libvirt supports migrating a guest to remote host but not local host.
>>
>
> Jim, is that right?
>
Opps, I missed this mail. Sorry for the delay.
Yes, that is correct
# virsh migrate --live test-pv xen+ssh:/
Konrad Rzeszutek Wilk wrote on 03/25/2015
04:27:00 PM:
> From: Konrad Rzeszutek Wilk
> To: Bjorn Helgaas ,
> Cc: Michael D Labriola , xen-
> de...@lists.xenproject.org, Stuart Wehrly ,
> michael.d.labri...@gmail.com, Jayson A Dyke , "Rafael
> J. Wysocki" , linux-...@vger.kernel.org, linux-
>
>>> diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
>>> index abf3d7a..8fe0650 100644
>>> --- a/xen/arch/x86/mm/hap/hap.c
>>> +++ b/xen/arch/x86/mm/hap/hap.c
>>> @@ -439,7 +439,7 @@ void hap_domain_init(struct domain *d)
>>> int hap_enable(struct domain *d, u32 mode)
>>> {
>>>
> > Thanks for the report, Michael, and sorry for the inconvenience. I think
> > the patch below will fix it, but I don't think it's the right fix either
> > because it seems a little ad hoc to sprinkle "acpi_pci_disabled" tests
> > around like fairy dust. I wonder if we can set things up so ACPI
On Wed, Mar 25, 2015 at 04:03:46PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 20, 2015 at 04:17:54PM -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez"
> >
> > This lets drivers take advanate of PAT when available. This
>
> s/advanate/advantage/
Amended.
> > should help with
On Tue, Mar 24, 2015 at 12:27:02PM -0500, Bjorn Helgaas wrote:
> [+cc Rafael, linux-pci, linux-acpi]
>
> On Tue, Mar 24, 2015 at 11:28:06AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Tue, Mar 24, 2015 at 11:14:29AM -0400, Michael D Labriola wrote:
> > > I'm having problems booting a 3.18 or newer
On Fri, Mar 20, 2015 at 04:17:55PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> This allows drivers to take advantage of write-combining
> when possible. Ideally we'd have pci_read_bases() just
> peg an IORESOURCE_WC flag for us but where exactly
> video devices memory lie vari
A job should be acquired at the beginning of a domain destroy operation,
not at the end when cleaning up the domain. Fix two occurances of this
late job acquisition in the libxl driver. Doing so renders
libxlDomainCleanup unused, so it is removed.
Signed-off-by: Jim Fehlig
---
src/libxl/libxl_
Let callers of libxlDomainStart decide when it is appropriate to
acquire a job on the associated virDomainObj.
Signed-off-by: Jim Fehlig
---
src/libxl/libxl_domain.c | 24 --
src/libxl/libxl_driver.c | 53 +++-
2 files changed, 52 i
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.
Patch 1 moves job acquisition from libxlDomainStart to it's callers so
A destroy operation can take considerable time on large memory
domains due to scrubbing the domain' memory. The operation is
running in the context of a job, so unlocking the domain and
allowing query operations is safe.
Signed-off-by: Jim Fehlig
---
src/libxl/libxl_domain.c | 4
src/libxl
On Fri, Mar 20, 2015 at 04:50:32PM -0700, Andy Lutomirski wrote:
> On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
> wrote:
> > From: "Luis R. Rodriguez"
> >
> > This lets drivers take advanate of PAT when available. This
> > should help with the transition of converting video drivers over
> >
On Fri, Mar 20, 2015 at 04:17:54PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> This lets drivers take advanate of PAT when available. This
s/advanate/advantage/
> should help with the transition of converting video drivers over
> to ioremap_wc() to help with the goal of event
On 03/25/15 11:48, Jan Beulich wrote:
On 25.03.15 at 16:02, wrote:
>> On 23/03/15 15:01, Don Slutz wrote:
>>> gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 reports:
>>> --
>>> hvm.c: In function `hvm_create_ioreq_server':
>>> hvm.
On Fri, Mar 20, 2015 at 04:17:52PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> It is possible to enable CONFIG_MTRR and up with it
> disabled at run time and yet CONFIG_X86_PAT continues
> to kick through fully functionally. This can happen
s/fully/full/ ?
> for instance on
On Fri, Mar 20, 2015 at 04:49:51PM -0700, Andy Lutomirski wrote:
> On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
> wrote:
> > From: "Luis R. Rodriguez"
> >
> > We have devm_ioremap_nocache() but no devm_ioremap_wc()
> > so add that. This will be used later.
> >
> > Cc: Suresh Siddha
> > Cc:
On Mon, Mar 16, 2015 at 02:16:13PM +0100, Peter Zijlstra wrote:
> Hi Waiman,
>
> As promised; here is the paravirt stuff I did during the trip to BOS last
> week.
>
> All the !paravirt patches are more or less the same as before (the only real
> change is the copyright lines in the first patch).
Hi Ian,
On 25/03/15 15:34, Ian Campbell wrote:
> Signed-off-by: Ian Campbell
Reviewed-by: Julien Grall
Regards,
> ---
> xen/arch/arm/domain.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index fdba081..939d8cd 10
Hi Ian,
On 25/03/15 14:22, Ian Campbell wrote:
> By adding GUEST_BUG_ON locally to traps.c.
>
> Signed-off-by: Ian Campbell
Reviewed-by: Julien Grall
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/
Hi Ian,
On 25/03/15 14:22, Ian Campbell wrote:
> 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 A
On Fri, Mar 13, 2015 at 09:26:08AM -0500, Bjorn Helgaas wrote:
> On Fri, Mar 13, 2015 at 9:01 AM, Konrad Rzeszutek Wilk
> wrote:
> > On Fri, Mar 13, 2015 at 08:24:58AM -0500, Bjorn Helgaas wrote:
> >> On Thu, Mar 12, 2015 at 9:36 PM, Yijing Wang wrote:
> >> > + pci_add_resource(&resources, &
Hi Ian,
On 25/03/15 14:22, Ian Campbell wrote:
> Previously we implemented all registers as RAZ/WI even if they
> shouldn't be accessible to userspace.
>
> Accesses to the *_EL1 registers from EL0 are trapped to EL1 by the
> hardware, so add a BUG_ON. Likewise accesses from 32-bit EL1 cannot
> ha
Hi Ian,
On 25/03/15 14:22, Ian Campbell wrote:
> 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 ha
Hi Ian,
On 25/03/15 14:22, Ian Campbell wrote:
> 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 t
On Tue, Mar 24, 2015 at 11:27:35AM -0400, Meng Xu wrote:
> 2015-03-24 7:54 GMT-04:00 George Dunlap :
>
> > On Tue, Mar 24, 2015 at 3:50 AM, Meng Xu wrote:
> > > Hi Dario and George,
> > >
> > > I'm exploring the design choice of eliminating the Xen scheduler
> > overhead on
> > > the dedicated CP
On Tue, Mar 24, 2015 at 03:22:55PM +, Ian Campbell wrote:
> On Mon, 2015-03-23 at 14:20 -0400, Konrad Rzeszutek Wilk wrote:
> > 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 f
On Tue, Mar 24, 2015 at 03:41:46PM +, Ian Campbell wrote:
> On Mon, 2015-03-23 at 14:21 -0400, Konrad Rzeszutek Wilk wrote:
> > 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 us
Hi Ian,
On 25/03/15 14:22, Ian Campbell wrote:
> -static void vtimer_cntp_tval(struct cpu_user_regs *regs, uint32_t *r, int
> read)
> +static int vtimer_cntp_tval(struct cpu_user_regs *regs, uint32_t *r, int
> read)
> {
> struct vcpu *v = current;
> s_time_t now;
>
> +if ( psr_m
On 25/03/15 16:23, Jan Beulich wrote:
__setup_msi_irq() needs to undo what it did before calling
write_msi_msg() in case that returned an error.
map_domain_pirq() needs to get rid of the MSI descriptor it
(implicitly) allocated. The case of a setup_msi_irq() failure on a
non-initial multi-vector
On 25/03/15 14:22, Ian Campbell wrote:
> +static int vtimer_cntp_cval(struct cpu_user_regs *regs, uint64_t *r, int
> read)
> +{
> +struct vcpu *v = current;
> +
> +if ( psr_mode_is_user(regs) &&
> + !(READ_SYSREG(CNTKCTL_EL1) & CNTKCTL_EL1_EL0PTEN) )
Sorry, I didn't notice it on m
Hi Ian,
On 25/03/15 14:22, Ian Campbell wrote:
> 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
Regards,
--
Julien Grall
Hi Ian,
On 25/03/15 14:22, Ian Campbell wrote:
> 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 fo
On 20/03/15 16:40, Jan Beulich wrote:
With ->startup unmasking the IRQ, setting the affinity afterwards
without masking the IRQ again is invalid namely for MSI (which can't
have their affinity updated atomically).
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
Changing the affini
On 20/03/15 14:53, Jan Beulich wrote:
- being non-atomic, their pointer arguments shouldn't be volatile-
qualified
- their (half fake) memory operands can be a single "+m" instead of
being both an output and an input
Signed-off-by: Jan Beulich
After further consideration, would it not b
>>
>> The second thing is how similar some of this is to nested p2m code,
>> making me wonder whether it could share more code with that. It's not
>> as much duplication as I had feared, but e.g. altp2m_write_p2m_entry()
>> is _identical_ to nestedp2m_write_p2m_entry(), (making the
>> copyright cl
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 passed through to the same domain and they
>
On Wed, Mar 25, 2015 at 05:04:38PM +, Jan Beulich wrote:
> >>> On 24.03.15 at 17:08, wrote:
> > +static int register_one_rmrr(struct acpi_rmrr_unit *rmrru)
> > +{
> > +bool_t ignore = 0;
> > +unsigned int i = 0;
> > +int ret = 0;
> > +
> > +/* Skip checking if segment is not ac
On 20/03/15 15:54, Jan Beulich wrote:
... at once eliminating some redundancy from the read variant (the cast
to the destination type can be done once outside the switch).
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing
On 01/15/2015 10:46 AM, Ed White wrote:
> On 01/15/2015 08:25 AM, Tim Deegan wrote:
>> Hi,
>>
>> At 13:26 -0800 on 09 Jan (1420806392), Ed White wrote:
>>> static inline bool_t is_epte_valid(ept_entry_t *e)
>>> {
>>> -return (e->epte != 0 && e->sa_p2mt != p2m_invalid);
>>> +return (e->val
On 20/03/15 16:04, Jan Beulich wrote:
1: introduce gprintk()
2: make {,g}dprintk() a no-op in non-debug builds
Signed-off-by: Jan Beulich
Both Reviewed-by: Andrew Cooper
It is likely that some other shifting of messages will happen, but lets
see what this looks like as a first pass.
~Andr
On Wed, 25 Mar 2015, Ian Campbell wrote:
> On Wed, 2015-03-25 at 10:44 +0100, Andrew Jones wrote:
> > Hello ARM virt maintainers,
> >
> > I'd like to start a discussion about supporting virt-what[1]. virt-what
> > allows userspace to determine if the system it's running on is running
> > in a gues
On Wed, Mar 25, 2015 at 08:53:01AM +, Dario Faggioli wrote:
> On Tue, 2015-03-24 at 16:29 -0400, Konrad Rzeszutek Wilk wrote:
> > On Tue, Mar 24, 2015 at 05:46:04PM +, Ian Campbell wrote:
> > > Is it necessary to worry about alignment here, since xc_cpumap_t is
> > > actually a uint8_t*.
>
On 25/03/15 17:09, Boris Ostrovsky wrote:
When querying CPU topology, if caller-provided array size is smaller than
number of online CPUs then, in addition to returning -ENOBUFS, sysctl is
expected to provide back this number. However, this value, stored in 'i',
is overwritten in the subsequent l
>>> On 24.03.15 at 17:08, wrote:
> +static int register_one_rmrr(struct acpi_rmrr_unit *rmrru)
> +{
> +bool_t ignore = 0;
> +unsigned int i = 0;
> +int ret = 0;
> +
> +/* Skip checking if segment is not accessible yet. */
> +if ( !pci_known_segment(rmrru->segment) )
> +
When querying CPU topology, if caller-provided array size is smaller than
number of online CPUs then, in addition to returning -ENOBUFS, sysctl is
expected to provide back this number. However, this value, stored in 'i',
is overwritten in the subsequent loop's control statement.
Make sure we don't
>>> On 17.03.15 at 15:54, wrote:
> Add support for privileged PMU mode (XENPMU_MODE_ALL) which allows privileged
> domain (dom0) profile both itself (and the hypervisor) and the guests. While
> this mode is on profiling in guests is disabled.
>
> Signed-off-by: Boris Ostrovsky
Acked-by: Jan Beu
>>> On 17.03.15 at 15:54, wrote:
> ---
> Changes in v19:
> * const-ified arch_vpmu_ops in vpmu_do_wrmsr
> * non-changes:
>- kept 'current' as a non-initializer to avoid unnecessary initialization
> in the (common) non-VPMU case
Afaict there's nothing at all keeping the compiler to still
flight 36719 ovmf real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/36719/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 7 windows-installfail REGR. vs. 36590
test-amd64-amd64-xl-win7-amd
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 intended effect
anymore. Even worse, for PCIe de
On Wed, 2015-03-25 at 16:14 +, Jan Beulich wrote:
> If the part of the compression data are corrupted, or the compression
> data is totally fake, the memory access over the limit is possible.
>
> This is the log from my system usning lz4 decompression.
>[6502]data abort, halting
>[6503
- __pci_enable_msix() now checks that an MSI-X capability was actually
found
- pass "pos" to msix_capability_init() as both callers already know it
(and hence there's no need to re-obtain it)
- call __pci_disable_msi{,x}() directly instead of via
pci_disable_msi() from __pci_enable_msi{x,}()
Rather than disabling and enabling MSI-X once per vector, do it just
once per device.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -1217,6 +1217,9 @@ int pci_restore_msi_state(struct pci_dev
struct msi_desc *entry, *tmp;
st
On 20/03/15 16:20, Jan Beulich wrote:
Its low 11 bits have different meaning.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
As done in Linux by f598282f51 ("PCI: Fix the NIU MSI-X problem in a
better way") and its broken predecessor, make sure we don't access the
MSI-X table without having enabled MSI-X first, using the mask-all flag
instead to prevent interrupts from occurring.
Signed-off-by: Jan Beulich
Reviewed-by:
On Wed, 2015-03-25 at 16:18 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH OSSTEST] Arrange for core dumps to be placed
> in /var/core and collect them"):
> > Do you have any thoughts on how to best universally arrange for the
> > rlimits to be increased? Probably inserting a ulimit
The problem requiring the first patch here is actually what lead to
XSA-120.
1: be more careful during teardown
2: access MSI-X table only after having enabled MSI-X
3: reduce fiddling with control register during restore
4: cleanup
Signed-off-by: Jan Beulich
(Only patch 1 really changed - see
Ian Campbell writes ("Re: [OSSTEST PATCH 29/32] ts-kernel-build: enable
CONFIG_SCSI_HPSA"):
> On Tue, 2015-03-24 at 19:02 +, Ian Jackson wrote:
> > +setopt CONFIG_SCSI_HPSA n
>
> This is disabling the option, not enabling it per the commit message.
Yes. I noticed that when I executed it :-/
On 19/03/15 22:53, Boris Ostrovsky wrote:
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -324,39 +324,63 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t)
u_sysctl)
}
break;
-case XEN_SYSCTL_topologyinfo:
+case XEN_SYSCTL_cputopoinfo:
{
-uint32_
__setup_msi_irq() needs to undo what it did before calling
write_msi_msg() in case that returned an error.
map_domain_pirq() needs to get rid of the MSI descriptor it
(implicitly) allocated. The case of a setup_msi_irq() failure on a
non-initial multi-vector-MSI interrupt needs special handling: W
Ian Campbell writes ("Re: [PATCH OSSTEST] Arrange for core dumps to be placed
in /var/core and collect them"):
> Do you have any thoughts on how to best universally arrange for the
> rlimits to be increased? Probably inserting a ulimit call into the
> libvirt initscript would be an easy first step
If the part of the compression data are corrupted, or the compression
data is totally fake, the memory access over the limit is possible.
This is the log from my system usning lz4 decompression.
[6502]data abort, halting
[6503]r0 0x r1 0x r2 0xdcea0ffc r3 0xdcea0ffc
[6
On 20/03/15 13:17, Vijay Kilari wrote:
Hi Andrew,
On Wed, Mar 11, 2015 at 4:21 PM, Andrew Cooper
wrote:
On 11/03/15 05:32, Vijay Kilari wrote:
Hi Andrew,
From Ian & Stefano, I came to know that you have introduced
Migration framework v2
under below patch series
http://marc.info/?l=xen
>>> On 25.03.15 at 10:27, wrote:
> On Wed, 2015-03-25 at 08:33 +, xen.org wrote:
>> flight 36695 xen-4.3-testing real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/36695/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could no
On Wed, 2015-03-25 at 15:41 +, Andrew Cooper wrote:
> On 25/03/15 15:34, 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.
> > - retur
>>> On 25.03.15 at 16:02, wrote:
> On 23/03/15 15:01, Don Slutz wrote:
>> gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 reports:
>> --
>> hvm.c: In function `hvm_create_ioreq_server':
>> hvm.c:487:18: error: `bufioreq_pfn' may be used
On 25/03/15 15:34, 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.
- return value goes in x0, not r0.
Hypercalls can only be made directly from kernel s
On Wed, 2015-03-25 at 15:34 +, Ian Campbell wrote:
Sigh, I remembered just too late that without a cover letter git doesn't
chain things, sorry. I should stop being so lazy...
> Signed-off-by: Ian Campbell
> ---
> xen/arch/arm/domain.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(
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.
- return value goes in x0, not r0.
Hypercalls can only be made directly from kernel space, so checking
the domain's size is suffic
PC only needs adjusting by 2, otherwise we rerun the instruction prior
to the hvc as well.
hvc is unpredictable if used within a Thumb IT (conditional execution)
block, so we don't need to worry about rewinding any of that state.
Signed-off-by: Ian Campbell
---
Should be backported
---
xen/arch
Signed-off-by: Ian Campbell
---
xen/arch/arm/domain.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index fdba081..939d8cd 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -742,7 +742,7 @@ int domain_relinquis
>>> On 25.03.15 at 03:32, wrote:
>> >>> On 19.01.15 at 10:00, wrote:
>> > --- a/xen/arch/x86/apic.c
>> > +++ b/xen/arch/x86/apic.c
>> > @@ -915,6 +915,11 @@ void __init x2apic_bsp_setup(void)
>> > return;
>> > }
>> > printk("x2APIC: Already enabled by BIOS: Ignoring
On 23/03/15 15:01, Don Slutz wrote:
> gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 reports:
> --
> hvm.c: In function `hvm_create_ioreq_server':
> hvm.c:487:18: error: `bufioreq_pfn' may be used uninitialised in this function
> [-Werro
On Wed, 2015-03-25 at 09:40 +, Ian Campbell wrote:
> Do you have any thoughts on how to best universally arrange for the
> rlimits to be increased? Probably inserting a ulimit call into the
> libvirt initscript would be an easy first step, and since that's the
> thing we most often see crashing
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.
-
Rather than using the v8 register names and the v7 bit names, which
makes things needlessly difficult when reading.
Signed-off-by: Ian Campbell
---
v3: New patch.
---
xen/arch/arm/time.c |2 +-
xen/include/asm-arm/processor.h |4 ++--
2 files changed, 3 insertions(+), 3 delet
Previously we implemented all registers as RAZ/WI even if they
shouldn't be accessible to userspace.
Accesses to the *_EL1 registers from EL0 are trapped to EL1 by the
hardware, so add a BUG_ON. Likewise accesses from 32-bit EL1 cannot
happen.
PMUSERENR_EL0 and MDCCSR_EL0 are R/O to EL0.
Other P
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
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 83abafa..4eda561 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
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).
CLIDR, CCSIDR, DCCISW, ACTLR, PMINT
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.
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
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
1 - 100 of 174 matches
Mail list logo
