>>> On 02.06.15 at 08:35, wrote:
> On Fri, May 29, 2015 at 09:52:03AM +0100, Jan Beulich wrote:
>> >>> On 29.05.15 at 10:28, wrote:
>> > On Fri, May 29, 2015 at 09:01:53AM +0100, Jan Beulich wrote:
>> >> >>> On 29.05.15 at 04:35, wrote:
>> >> > On Thu, May 28, 2015 at 01:38:05PM +0100, Jan Beuli
flight 57730 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57730/
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
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, June 02, 2015 2:30 PM
>
> >>> On 02.06.15 at 02:39, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Monday, June 01, 2015 5:17 PM
> >> >>> On 01.06.15 at 08:30, wrote:
> >> >> From: elena.ufimts...@oracle.com
>
On Fri, May 29, 2015 at 09:52:03AM +0100, Jan Beulich wrote:
> >>> On 29.05.15 at 10:28, wrote:
> > On Fri, May 29, 2015 at 09:01:53AM +0100, Jan Beulich wrote:
> >> >>> On 29.05.15 at 04:35, wrote:
> >> > On Thu, May 28, 2015 at 01:38:05PM +0100, Jan Beulich wrote:
> >> >> >>> On 21.05.15 at 10:
>>> On 02.06.15 at 05:23, wrote:
> On 26/05/2015 21:58, Jan Beulich wrote
>> >>> On 13.05.16 at 09:50, wrote:
>> > +id = x86_match_cpu(intel_pstate_cpu_ids);
>> > +if (!id)
>> > +return -ENODEV;
>> > +
>> > +cpu_info = (struct cpu_defaults *)id->driver_data;
>> > +
>> > +c
>>> On 02.06.15 at 02:39, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Monday, June 01, 2015 5:17 PM
>> >>> On 01.06.15 at 08:30, wrote:
>> >> From: elena.ufimts...@oracle.com
>> >> --- a/docs/misc/xen-command-line.markdown
>> >> +++ b/docs/misc/xen-command-line.markdown
>>
If the host EPT entry is changed, the nested EPT should be updated.
The current code does not do this, and it's wrong.
Reported-by: Tim Deegan
Signed-off-by: Liang Li
Signed-off-by: Yang Zhang
---
xen/arch/x86/mm/p2m-ept.c | 4
1 file changed, 4 insertions(+)
diff --git a/xen/arch/x86/mm
flight 57721 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57721/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 56492
test-amd64-i386-xl-qemuu-win
On 26/05/2015 21:58, Jan Beulich wrote
> >>> On 13.05.16 at 09:50, wrote:
> > +id = x86_match_cpu(intel_pstate_cpu_ids);
> > +if (!id)
> > +return -ENODEV;
> > +
> > +cpu_info = (struct cpu_defaults *)id->driver_data;
> > +
> > +copy_pid_params(&cpu_info->pid_policy);
> > +
flight 57713 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57713/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 3 host-install(3) broken in 57645 REGR. vs. 57312
test-amd64-i386-xl-qem
flight 57712 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57712/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail REGR. vs.
57419
build-armhf-xsm
flight 57718 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57718/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 3 host-install(3) broken REGR. vs. 53854
test-amd64-i386-libvirt
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, June 01, 2015 5:17 PM
>
> >>> On 01.06.15 at 08:30, wrote:
> >> From: elena.ufimts...@oracle.com
> [mailto:elena.ufimts...@oracle.com]
> >> --- a/docs/misc/xen-command-line.markdown
> >> +++ b/docs/misc/xen-command-line.markdown
> >>
Hi Dave,
On Mon, 01 Jun 2015 15:59:31 -0700 (PDT) David Miller
wrote:
>
> From: Stephen Rothwell
> Date: Fri, 29 May 2015 19:18:47 +1000
>
> > Nothing in asm/io.h uses anything from vmalloc.h, so remove the include
> > and fix up the build problems in an allmodconfig (64 bit and 32 bit)
> > bu
flight 57697 xen-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57697/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xend-winxpsp3 16 guest-stop fail REGR. vs. 53018
test-amd64-i386-x
From: Stephen Rothwell
Date: Fri, 29 May 2015 19:18:47 +1000
> Nothing in asm/io.h uses anything from vmalloc.h, so remove the include
> and fix up the build problems in an allmodconfig (64 bit and 32 bit)
> build.
>
> This may be the place where x86 builds get vmalloc.h implicitly included
> an
On Tuesday 26 May 2015 06:04 AM, Ian Campbell wrote:
On Thu, 2015-05-21 at 05:37 -0700, Manish Jaggi wrote:
On Tuesday 19 May 2015 07:18 AM, Ian Campbell wrote:
On Tue, 2015-05-19 at 19:34 +0530, Vijay Kilari wrote:
On Tue, May 19, 2015 at 7:24 PM, Ian Campbell wrote:
On Tue, 2015-05-19 at
On Mon, Jun 1, 2015 at 4:24 AM, Ian Campbell wrote:
> On Mon, 2015-06-01 at 12:10 +0100, Jan Beulich wrote:
>> >>> On 01.06.15 at 12:17, wrote:
>> > If calling ExitBootServices() fails, the required memory map size may
>> > have increased. When initially allocating the memory map, allocate a
>> >
branch xen-unstable
xen branch xen-unstable
job test-armhf-armhf-xl-multivcpu
test leak-check/check
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
On 06/01/2015 06:19 AM, Wei Liu wrote:
Make the setup process similar to PV counterpart. That is, to allocate a
P2M array that covers the whole memory range and start from there. This
is clearer than using an array with no holes in it.
Also the dummy layout should take MMIO hole into considerati
From: Ian Campbell
Date: Mon, 1 Jun 2015 11:30:04 +0100
> drivers/net/xen-netback/netback.c: In function ‘xenvif_tx_build_gops’:
> drivers/net/xen-netback/netback.c:1253:8: warning: format ‘%lu’ expects
> argument of type ‘long unsigned int’, but argument 5 has type ‘int’
> [-Wformat=]
>
From: Ian Campbell
Date: Mon, 1 Jun 2015 11:30:24 +0100
> When we come to tear things down in netback_remove() and generate the
> uevent it is possible that the xenstore directory has already been
> removed (details below).
>
> In such cases netback_uevent() won't be able to read the hotplug
> s
On Mon, Jun 01, 2015 at 10:36:25AM +0100, Lars Kurth wrote:
> Hi,
>
> in accordance with the project's governance, I would like to put the
> following text changes to a committer vote (committers are on the TO list).
> The discussion leading to the changes can be found at
> http://lists.xenproj
On Mon, Jun 01, 2015 at 05:03:14PM +0100, Malcolm Crossley wrote:
> On 01/06/15 16:43, Ross Lagerwall wrote:
> > On 06/01/2015 04:26 PM, Konrad Rzeszutek Wilk wrote:
> >> On Fri, May 29, 2015 at 08:59:45AM +0100, Ross Lagerwall wrote:
> >>> When doing passthrough of a PCI device for an HVM guest, d
I discovered some problems as I played along with my OSSTest stubdom test case.
Here are two patches to fix them.
Wei.
Wei Liu (2):
libxl: remove code in stubdom creation failure path and callback
libxl: clean up qemu-save and qemu-resume files
tools/libxl/libxl.c| 9 +
tools/l
The snippet to destroy stubdom and the callback were added in 1fc3aeb3
("libxl: use new QEMU xenstore protocol"). The intention was to destroy
stubdom when it is not responsive. That approach is problematic because
rc is not propagate back to sdss->callback, hence the guest is leaked.
The solution
These files are leaked when using qemu-trad stubdom. They are
intermediate files created by libxc. Unfortunately they don't fit well
in our userdata scheme. Clean them up after we destroy guest, we're
sure they are not useful anymore at that point.
Signed-off-by: Wei Liu
---
tools/libxl/libxl.c
Try to use "xen-qemudepriv-$domname" first, then
"xen-qemudepriv-domid$domid", finally "xen-qemudepriv-shared" and root
if everything else fails.
The uids need to be manually created by the user or, more likely, by the
xen package maintainer.
To actually secure QEMU when running in Dom0, we need
On Fri, 29 May 2015, Ian Campbell wrote:
> On Fri, 2015-05-29 at 14:47 +0100, Stefano Stabellini wrote:
> > Try to use "xen-qemudepriv-$domname" first, then "xen-qemudepriv-base" +
> > domid, finally "xen-qemudepriv-shared" and root if everything else fails.
> >
> > The uids need to be manually cr
On Mon, Jun 01, 2015 at 09:53:55AM +0100, Jan Beulich wrote:
> >>> On 29.05.15 at 23:38, wrote:
> > In preparation for auxiliary RMRR data provided on Xen
> > command line, make RMRR adding a separate function.
> > Also free memery for rmrr device scope in error path.
> > No changes since v5.
>
>
On Mon, 2015-06-01 at 17:09 +0100, Anthony PERARD wrote:
> On Mon, Jun 01, 2015 at 04:17:51PM +0100, Ian Campbell wrote:
> > On Mon, 2015-06-01 at 16:08 +0100, Jan Beulich wrote:
> > > >>> On 01.06.15 at 16:59, wrote:
> > > > --- a/tools/hotplug/Linux/vif-common.sh
> > > > +++ b/tools/hotplug/Linu
On Mon, Jun 01, 2015 at 04:51:55AM +, Tian, Kevin wrote:
> > From: elena.ufimts...@oracle.com [mailto:elena.ufimts...@oracle.com]
> > Sent: Saturday, May 30, 2015 5:39 AM
> >
> > From: Elena Ufimtseva
> >
> > In preparation for auxiliary RMRR data provided on Xen
> > command line, make RMRR
On Mon, Jun 01, 2015 at 05:09:56PM +0100, Anthony PERARD wrote:
> On Mon, Jun 01, 2015 at 04:17:51PM +0100, Ian Campbell wrote:
> > On Mon, 2015-06-01 at 16:08 +0100, Jan Beulich wrote:
> > > >>> On 01.06.15 at 16:59, wrote:
> > > > --- a/tools/hotplug/Linux/vif-common.sh
> > > > +++ b/tools/hotpl
On Mon, Jun 01, 2015 at 04:17:51PM +0100, Ian Campbell wrote:
> On Mon, 2015-06-01 at 16:08 +0100, Jan Beulich wrote:
> > >>> On 01.06.15 at 16:59, wrote:
> > > --- a/tools/hotplug/Linux/vif-common.sh
> > > +++ b/tools/hotplug/Linux/vif-common.sh
> > > @@ -130,9 +130,9 @@ frob_iptable()
> > >
On 01/06/15 16:43, Ross Lagerwall wrote:
> On 06/01/2015 04:26 PM, Konrad Rzeszutek Wilk wrote:
>> On Fri, May 29, 2015 at 08:59:45AM +0100, Ross Lagerwall wrote:
>>> When doing passthrough of a PCI device for an HVM guest, don't insert
>>> the device into xenstore, otherwise pciback attempts to us
When QEMU restricts its xenstore connection, it cannot provide PV
backends. A separate QEMU instance is required to provide PV backends in
userspace, such as qdisk. With two separate instances, it is not
possible to take advantage of vkb for mouse and keyboard, as the QEMU
that emulates the graphic
The device model is going to restrict its xenstore connection to $DOMID
level. Let it access /local/domain/0/device-model/$DOMID, as it is
required by QEMU to read/write the physmap. It doesn't contain any
information the guest is not already fully aware of.
Signed-off-by: Stefano Stabellini
---
Hi all,
this is an incomplete patch series to allow testing QEMU with the new
xsrestrict option
(http://marc.info/?l=qemu-devel&m=143317363104584&w=2). I use it
together with the attached script to start multiple QEMUs, one is the
regular QEMU device model for hvm guests, the other provides the PV
>>> On 01.06.15 at 17:26, wrote:
> --- a/xen/common/hvm/save.c
> +++ b/xen/common/hvm/save.c
This being an x86-specific problem I would think this would better be
addressed in x86-specific code. If it was to stay here, a proper
arch hook should be introduced (even if ARM isn't using this code
rig
Monday, June 1, 2015, 5:43:53 PM, you wrote:
> On 06/01/2015 04:26 PM, Konrad Rzeszutek Wilk wrote:
>> On Fri, May 29, 2015 at 08:59:45AM +0100, Ross Lagerwall wrote:
>>> When doing passthrough of a PCI device for an HVM guest, don't insert
>>> the device into xenstore, otherwise pciback attempts
On Mon, Jun 01, 2015 at 04:43:53PM +0100, Ross Lagerwall wrote:
> On 06/01/2015 04:26 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, May 29, 2015 at 08:59:45AM +0100, Ross Lagerwall wrote:
> >>When doing passthrough of a PCI device for an HVM guest, don't insert
> >>the device into xenstore, otherwise
Introduce a new command line option "xenopts", with one boolean
suboption "xsrestrict". When xsrestrict=on is passed, QEMU will
restrict the xenstore connection calling xs_restrict. Also it won't
initialize the pv backends as they require higher privileges.
It requires a toolstack change to allow
On 01/06/15 14:18, Zoltan Kiss wrote:
> Sure. Btw. do you have them in a public repo somewhere? It would make it
> a little bit easier to apply and test.
It's based on the latest staging:
http://xenbits.xen.org/gitweb/?p=people/julieng/xen-unstable.git;a=shortlog;h=refs/heads/for-huawei/gicv2-on-
Hi all,
this patch series introduces a new command line option to restrict the
privilege of the xenstore connection. Used together with -runas, can
help secure the execution of QEMU in Dom0.
Stefano Stabellini (2):
xen: separate the xenstore_record_dm_state calls for pv and hvm machines
An MTRR record is processed for each vCPU during hvm_load. Each MTRR
record sets several mtrrs, each of which flushes the cache on all pCPUs.
This can take some time and trip the watchdog for HVM guests with many
CPUs.
To fix this, introduce a flag which prevents flushing the cache when
doing MTRR
On 01/06/15 14:12, Ian Campbell wrote:
> On Fri, 2015-05-29 at 14:40 +0100, Julien Grall wrote:
>> Hi Ian,
Hi Ian,
>> NIT: You used my Linaro email which I think is de-activated now :).
>
> I keep finding new address books with that address in them!
>
>>> ## ITS Translation Table
>>>
>>> Messa
On 06/01/2015 04:26 PM, Konrad Rzeszutek Wilk wrote:
On Fri, May 29, 2015 at 08:59:45AM +0100, Ross Lagerwall wrote:
When doing passthrough of a PCI device for an HVM guest, don't insert
the device into xenstore, otherwise pciback attempts to use it which
conflicts with QEMU.
How does it confl
The following patch will introduce a new option to restrict the
privilege of the xenstore connection. In that case, we do not want to
use multiple xenstore connections, but just the one, with lower
privileges.
For this reason, split the xenstore_record_dm_state calls for pv and hvm
machines, so th
On Fri, May 29, 2015 at 08:59:45AM +0100, Ross Lagerwall wrote:
> When doing passthrough of a PCI device for an HVM guest, don't insert
> the device into xenstore, otherwise pciback attempts to use it which
> conflicts with QEMU.
How does it conflict?
>
> This manifests itself such that the first
On Mon, Jun 01, 2015 at 09:45:51AM +0100, Jan Beulich wrote:
> >>> On 01.06.15 at 06:47, wrote:
> >> From: Tian, Kevin
> >> Sent: Monday, June 01, 2015 12:43 PM
> >>
> >>
> >> and looks you dropped earlier changes to acpi_parse_one_rmrr. any
> >> elaboration why it's not required in this versio
Currently only QEMU traditional supports stubdom, so we only create
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
Note that stubdom only supports serial='pty'. Piping serial to stderr
causes stubdom to exit abnormally.
Signed-off-by:
On Mon, 2015-06-01 at 16:08 +0100, Jan Beulich wrote:
> >>> On 01.06.15 at 16:59, wrote:
> > --- a/tools/hotplug/Linux/vif-common.sh
> > +++ b/tools/hotplug/Linux/vif-common.sh
> > @@ -130,9 +130,9 @@ frob_iptable()
> > local c="-D"
> >fi
> >
> > - iptables "$c" FORWARD -m physdev --ph
>>> On 01.06.15 at 16:59, wrote:
> --- a/tools/hotplug/Linux/vif-common.sh
> +++ b/tools/hotplug/Linux/vif-common.sh
> @@ -130,9 +130,9 @@ frob_iptable()
> local c="-D"
>fi
>
> - iptables "$c" FORWARD -m physdev --physdev-is-bridged --physdev-in "$dev" \
> + iptables --wait "$c" FORWA
This help to avoid guest creation error when a downstream project is also
updating the iptables at guest creation time.
The error seen is this one:
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus:
/etc/xen/scripts/vif-bridge online [-1] exited with error status 4
Apparently, exit
flight 57680 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57680/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 3 host-install(3) broken REGR. vs. 53768
test-amd64-i386-x
Change frontswap single pointer to a singly linked list of frontswap
implementations. Update Xen tmem implementation as register no longer
returns anything.
Frontswap only keeps track of a single implementation; any implementation
that registers second (or later) will replace the previously regis
>>> On 01.06.15 at 15:56, wrote:
> On Mon, 2015-06-01 at 14:50 +0100, Jan Beulich wrote:
>> It's being removed in Linux 4.1.
>>
>> Signed-off-by: Jan Beulich
>
> Not sure who should, but:
I guess no-one really needs to for that old code. But thanks!
Jan
_
It's being removed in Linux 4.1.
Signed-off-by: Jan Beulich
--- a/unmodified_drivers/linux-2.6/platform-pci/evtchn.c
+++ b/unmodified_drivers/linux-2.6/platform-pci/evtchn.c
@@ -350,11 +350,13 @@ int xen_irq_init(struct pci_dev *pdev)
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,22)
On Mon, 2015-06-01 at 14:50 +0100, Jan Beulich wrote:
> It's being removed in Linux 4.1.
>
> Signed-off-by: Jan Beulich
Not sure who should, but:
Acked-by: Ian Campbell
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-d
flight 57676 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57676/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail
REGR. vs. 56941
Tests
On Mon, 2015-06-01 at 13:24 +0100, Julien Grall wrote:
> On 01/06/15 13:11, Ian Campbell wrote:
> >>> ### Device ID (`ID`)
> >>>
> >>> This parameter is used by commands which manage a specific device and
> >>> the interrupts associated with that device. Checking if a device is
> >>> present and re
On Fri, 2015-05-29 at 15:06 +0100, Julien Grall wrote:
> Hi Vijay,
>
> On 27/05/15 17:44, Vijay Kilari wrote:
> >> ## Command Translation
> >>
> >> Of the existing GICv3 ITS commands, `MAPC`, `MAPD`, `MAPVI`/`MAPI` are
> >> potentially time consuming commands as these commands creates entry in
> >
On Mon, Jun 01, 2015 at 03:26:58PM +0200, Daniel Kiper wrote:
[...]
> > > tools/misc/Makefile |2 +-
> > > tools/xenstat/xentop/Makefile |2 +-
> > > 5 files changed, 53 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/config/Tools.mk.in b/config/Tools.mk.in
> > > index d67
On Mon, Jun 01, 2015 at 02:06:44PM +0100, Wei Liu wrote:
> On Sat, May 30, 2015 at 12:07:28AM +0200, Daniel Kiper wrote:
> > binutils 2.22 changed ld default from --copy-dt-needed-entries
> > to -no-copy-dt-needed-entries. This revealed that some objects
> > are linked implicitly with libtinfo and
On Fri, May 22, 2015 at 11:18:55AM +0200, Roger Pau Monne wrote:
> FreeBSD blkback uses the path xenstore node in order to fetch the path to
> the underlying backing storage (either a block device or raw image). This
> node is set by the hotplug scripts.
>
> Signed-off-by: Roger Pau Monné
> Cc: I
On 05/12/2015 03:06 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 01/06/15 13:11, Julien Grall wrote:
On 01/06/15 12:25, Zoltan Kiss wrote:
Hi,
Yes, we managed to test it, and it works. Then only thing I've found is
this bit:
+/* Only 1020 interrupts are supported */
+gicv2_info.nr_lines = min(1020U, nr_lines);
This interrupt controller only su
On Fri, 2015-05-29 at 14:40 +0100, Julien Grall wrote:
> Hi Ian,
>
> NIT: You used my Linaro email which I think is de-activated now :).
I keep finding new address books with that address in them!
> > ## ITS Translation Table
> >
> > Message signalled interrupts are translated into an LPI via a
On Sat, May 30, 2015 at 12:07:28AM +0200, Daniel Kiper wrote:
> binutils 2.22 changed ld default from --copy-dt-needed-entries
> to -no-copy-dt-needed-entries. This revealed that some objects
> are linked implicitly with libtinfo and newer ld fails to build
> relevant executables.
>
> Below is sho
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 not necessary big at the
moment. Consideri
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
evtchn_init will call domain_max_vcpus to allocate poll_mask. On
arm/arm64 platform, this number is determined by the vGIC the guest
is going to use, which won't be initialised until arch_domain_create
is called in current implementation. However, moving arch_domain_create
means
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
---
xen/arch/arm/domain_build
From: Chen Baozi
Use cpumask_t instead of unsigned long which can only express 64 cpus at
the most. Add the {gicv2|gicv3}_sgir_to_cpumask in corresponding vGICs
to translate GICD_SGIR/ICC_SGI1R_EL1 to vcpu_mask for vgic_to_sgi.
Signed-off-by: Chen Baozi
---
xen/arch/arm/vgic-v2.c|
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
---
From: Chen Baozi
To support more than 16 vCPUs, we have to calculate cpumask with AFF1
field value in ICC_SGI1R_EL1.
Signed-off-by: Chen Baozi
---
xen/arch/arm/vgic-v3.c| 30 ++
xen/include/asm-arm/gic_v3_defs.h | 2 ++
2 files changed, 28 insertions(+)
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
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
GICv3 restricts that the maximum number of CPUs in affinity 0 (one
cluster) is 16. That is to say the upper 4 bits of affinity 0 is unused.
Current implementation considers that AFF0 is equal to vCPUID, which
makes all vCPUs in one cluster, limiting its number to 16. If we would
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
---
xen/include/public/arch-arm.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletio
On Fri, May 29, 2015 at 6:07 PM, Andrew Morton
wrote:
> On Thu, 28 May 2015 16:28:37 -0400 Dan Streetman wrote:
>
>> Change frontswap single pointer to a singly linked list of frontswap
>> implementations. Update Xen tmem implementation as register no longer
>> returns anything.
>>
>> Frontswap
On 01/06/15 13:11, Ian Campbell wrote:
>>> ### Device ID (`ID`)
>>>
>>> This parameter is used by commands which manage a specific device and
>>> the interrupts associated with that device. Checking if a device is
>>> present and retrieving the data structure must be fast.
>>>
>>> The device identi
flight 57717 rumpuserxen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57717/
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 01/06/15 12:25, Zoltan Kiss wrote:
> Hi,
>
> Yes, we managed to test it, and it works. Then only thing I've found is
> this bit:
>
> +/* Only 1020 interrupts are supported */
> +gicv2_info.nr_lines = min(1020U, nr_lines);
>
> This interrupt controller only supports 511, so 1020 should
On Wed, 2015-05-27 at 22:14 +0530, Vijay Kilari wrote:
> > ## pITS Scheduling
> >
> > A pITS scheduling pass is attempted:
> >
> > * On write to any virtual `CWRITER` iff that write results in there
> > being new outstanding requests for that vits;
>
>You mean, scheduling pass (softirq trigg
flight 57671 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57671/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 3 host-install(3) broken REGR. vs. 57442
Hi,
Yes, we managed to test it, and it works. Then only thing I've found is
this bit:
+/* Only 1020 interrupts are supported */
+gicv2_info.nr_lines = min(1020U, nr_lines);
This interrupt controller only supports 511, so 1020 should be replaced.
We had such checking in the code in th
On Mon, Jun 01, 2015 at 11:30:24AM +0100, Ian Campbell wrote:
> When we come to tear things down in netback_remove() and generate the
> uevent it is possible that the xenstore directory has already been
> removed (details below).
>
> In such cases netback_uevent() won't be able to read the hotplug
On Mon, 2015-06-01 at 12:10 +0100, Jan Beulich wrote:
> >>> On 01.06.15 at 12:17, wrote:
> > If calling ExitBootServices() fails, the required memory map size may
> > have increased. When initially allocating the memory map, allocate a
> > slightly larger buffer (by an arbitrary 8 entries) to fix
On Mon, Jun 01, 2015 at 11:30:04AM +0100, Ian Campbell wrote:
> drivers/net/xen-netback/netback.c: In function ‘xenvif_tx_build_gops’:
> drivers/net/xen-netback/netback.c:1253:8: warning: format ‘%lu’ expects
> argument of type ‘long unsigned int’, but argument 5 has type ‘int’
> [-Wformat=]
>
On Mon, 2015-06-01 at 12:13 +0100, Julien Grall wrote:
> Hi,
>
> On 18/05/15 14:36, Zoltan Kiss wrote:
> >
> >
> > On 15/05/15 22:08, Julien Grall wrote:
> >> Hi Zoltan,
> >>
> >> On 07/05/2015 13:37, Zoltan Kiss wrote:
> >>
> >>> On 07/05/15 10:32, Ian Campbell wrote:
> On Thu, 2015-05-07
Hi,
On 18/05/15 14:36, Zoltan Kiss wrote:
>
>
> On 15/05/15 22:08, Julien Grall wrote:
>> Hi Zoltan,
>>
>> On 07/05/2015 13:37, Zoltan Kiss wrote:
>>
>>> On 07/05/15 10:32, Ian Campbell wrote:
On Thu, 2015-05-07 at 09:52 +0100, Zoltan Kiss wrote:
> Looks good at first glance, let me try
>>> On 01.06.15 at 12:17, wrote:
> If calling ExitBootServices() fails, the required memory map size may
> have increased. When initially allocating the memory map, allocate a
> slightly larger buffer (by an arbitrary 8 entries) to fix this.
>
> The ARM code path was already allocating a larger b
>>> On 29.05.15 at 20:42, wrote:
> No need to compute those masks on every MSR access.
>
> Also, when checking MSR_P6_EVNTSELx registers make sure that bit 21
> is not set.
I had hoped you would save me and other readers to look up what
this bit means by giving a reason why this change is wanted
On 30/05/15 14:43, Gautam Malu wrote:
> Hi,
Hello,
It's not necessary to send the same mail twice at one day of interval.
The mail will be answered as soon as we can...
The xen-arm mailing list has been archived few months ago and this
question should be asked on xen-users given it's more a conf
>>> On 01.06.15 at 12:26, wrote:
> On 01/06/15 11:17, Ross Lagerwall wrote:
>> --- a/xen/common/efi/boot.c
>> +++ b/xen/common/efi/boot.c
>> @@ -216,6 +216,12 @@ static void __init noreturn blexit(const CHAR16 *str)
>> PrintStr((CHAR16 *)str);
>> PrintStr(newline);
>>
>> +if (
When we come to tear things down in netback_remove() and generate the
uevent it is possible that the xenstore directory has already been
removed (details below).
In such cases netback_uevent() won't be able to read the hotplug
script and will write a xenstore error node.
A recent change to the hy
drivers/net/xen-netback/netback.c: In function ‘xenvif_tx_build_gops’:
drivers/net/xen-netback/netback.c:1253:8: warning: format ‘%lu’ expects
argument of type ‘long unsigned int’, but argument 5 has type ‘int’ [-Wformat=]
(txreq.offset&~PAGE_MASK) + txreq.size);
^
PAGE_MASK's typ
On 01/06/15 11:17, Ross Lagerwall wrote:
> After the first call to ExitBootServices(), avoid calling any boot
> services by setting setting efi_bs to NULL and entering an infinite loop
> in blexit().
>
> Signed-off-by: Ross Lagerwall
> ---
> xen/common/efi/boot.c | 16 +---
> 1 file c
flight 57666 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57666/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 17 leak-check/check fail REGR. vs. 56831
Tests which are fai
1 - 100 of 151 matches
Mail list logo
