To ARM64, "frametable_size >> SECOND_SHIFT" means the number
of second level entries, not the number of second level pages.
"DIV_ROUND_UP(frametable_size >> SECOND_SHIFT, LPAE_ENTRIES)"
is the correct way to calculate the second level pages needed
for frametable mapping.
Signed-off-by: Peng Fan
Add a backend for para-virtualized USB devices for xen domains.
The backend is using host-libusb to forward USB requests from a
domain via libusb to the real device(s) passed through.
Signed-off-by: Juergen Gross
Acked-by: Anthony PERARD
---
V3: multiple small changes as requested by Anthony Pe
Introduce a new dummy system device serving as parent for virtual
buses. This will enable new pv backends to introduce virtual buses
which are removable again opposed to system buses which are meant
to stay once added.
Signed-off-by: Juergen Gross
Acked-by: Anthony PERARD
---
V2: NOT changed, ev
This series adds a Xen pvUSB backend driver to qemu. USB devices
connected to the host can be passed through to a Xen guest. The
devices are specified via Xenstore. Access to the devices is done
via host-libusb.c
I've tested the backend with various USB devices (memory sticks,
keyboard, ...).
Cha
Add a Xenstore directory for each supported pv backend. This will allow
Xen tools to decide which backend type to use in case there are
multiple possibilities.
The information is added under
/local/domain//device-model//backends
before the "running" state is written to Xenstore. Using a directory
Gentle ping...
On 03/03/16 10:38, Juergen Gross wrote:
> The Xen hypervisor supports starting a dom0 with large memory (up to
> the TB range) by not including the initrd and p2m list in the initial
> kernel mapping. Especially the p2m list can grow larger than the
> available virtual space in the
On May 11, 2016 5:07 PM, Jan Beulich wrote:
> >>> On 11.05.16 at 10:35, wrote:
> > On May 10, 2016 5:29 PM, Jan Beulich wrote:
> >> >>> On 06.05.16 at 10:54, wrote:
> >> > @@ -1430,7 +1430,12 @@ int domain_context_mapping_one(
> >> > unmap_vtd_domain_page(context_entries);
> >> >
> >> >
Hi Boris,
On 05/10/2016 02:11 PM, Boris Ostrovsky wrote:
> On 05/10/2016 12:11 PM, Kevin Moraga wrote:
> Can you boot your system bare-metal and post output of 'biosdecode' command?
>
> -boris
Sure, it's attached.
--
Sincerely,
Kevin Moraga
PGP: F258EDCB
Fingerprint: 3915 A5A9 959C D18F 0A89 B47
flight 94027 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94027/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i386-rumpuserxen6 xen-buildfail like 93503
build-amd64-rumpuserxen 6
On 2016/5/12 7:24, Matt Fleming wrote:
> On Wed, 11 May, at 09:35:47PM, Shannon Zhao wrote:
>>> > >
>>> > > Also, why do you need to setup efi.runtime_version here? Isn't that
>>> > > done inside uefi_init()?
>>> > >
>> > I don't see any codes which setup efi.runtime_version in uefi_init().
>
flight 94021 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94021/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i386-rumpuserxen6 xen-buildfail like 93920
build-amd64-rumpuserxen
In setup_pagetables, need to map BOOT_RELOC_VIRT_START
in xen_second and boot_second, so we can merge the two
pieces code into one code block.
Also no need to use write_pte when map BOOT_RELOC_VIRT_START
in xen_second, because CPU0 is using boot page tables now.
Signed-off-by: Peng Fan
Cc: Stefa
CPU0 is using the boot pages table before relocating xen and
xen_second is not part of them. So, no need to flush the TLB
when filling xen_second.
Signed-off-by: Peng Fan
Cc: Stefano Stabellini
Cc: Julien Grall
---
V2:
Following Julien's comments:
split the V1 patch into two patches. This
flight 94023 qemu-upstream-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94023/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pv 17 guest-localmigrate/x10fail REGR. vs. 83041
Tests w
Hi Dushyant,
On Tue, Mar 8, 2016 at 3:23 AM, Dushyant K Behl wrote:
>
> Hi All,
>
> I'm working on a research project with IBM, and I want to run Xen on Nvidia
> Tegra Jetson-tk1 board.
> I looked at a post on this mailing list
> (http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg0
On 05/11/2016 12:01 AM, Olaf Hering wrote:
> On Mon, May 02, Jim Fehlig wrote:
>
>> In LIBXL_API_VERSION 0x040400, the libxl_domain_create_restore API
>> gained a parameter for specifying restore parameters. Switch to
>> using version 0x040400, which will be useful in a subsequent commit
>> to spec
On Wed, 11 May, at 09:35:47PM, Shannon Zhao wrote:
> >
> > Also, why do you need to setup efi.runtime_version here? Isn't that
> > done inside uefi_init()?
> >
> I don't see any codes which setup efi.runtime_version in uefi_init().
Look in the EFI tree,
https://git.kernel.org/cgit/linux/ker
flight 94010 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94010/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-amd64-xl-qemuu-ov
flight 94043 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94043/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-ovmf-amd64
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenb
This run is configured for baseline tests only.
flight 44406 xen-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44406/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 4 capture-logs
flight 94018 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94018/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 guest-saverestorefail never pass
test-armhf-armhf-libvirt 12 migrate-sup
flight 94019 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94019/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3863 host-install(3) broken REG
On 5/11/16 4:53 AM, Jan Beulich wrote:
On 10.05.16 at 23:05, wrote:
>> Convert the 'perfc' and 'perfc_arrays' options to Kconfig as
>> CONFIG_PERF_COUNTERS and CONFIG_PERF_ARRAYS to minimize code changes.
>
> I don't understand the "to minimize code changes" part.
Instead of calling the opt
On 5/11/16 4:45 AM, Jan Beulich wrote:
On 10.05.16 at 23:05, wrote:
>> --- a/xen/Kconfig.debug
>> +++ b/xen/Kconfig.debug
>> @@ -15,4 +15,11 @@ config DEBUG
>>option is intended for development purposes only, and not for
>>production use.
>>
>> +config VERBOSE_DEBUG
>> +
On 5/11/16 4:47 AM, Jan Beulich wrote:
On 10.05.16 at 23:05, wrote:
>> --- a/xen/Kconfig.debug
>> +++ b/xen/Kconfig.debug
>> @@ -1,6 +1,13 @@
>>
>> menu "Debugging Options"
>>
>> +config CRASH_DEBUG
>> +bool "Crash Debugging Support"
>> +depends on X86
>> +---help---
>> +
flight 94001 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94001/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xend-qemut-winxpsp3 9 windows-installfail REGR. vs. 92242
Regressions which
flight 94032 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94032/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
Hi Fangtuo,
#VE can be setup to be delivered to any dom that is a HVM.
Ravi
From: Big Strong [mailto:fangtu...@gmail.com]
Sent: Wednesday, May 11, 2016 8:38 AM
To: Wei Liu
Cc: Tamas K Lengyel ; Sahita, Ravi
; Xen-devel
Subject: Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail
Is that a
On Wed, May 11, 2016 at 04:33:34PM +0100, Paul Durrant wrote:
> My recent patch to include/xen/interface/io/netif.h defines a new shared
> ring (in addition to the rx and tx rings) for passing control messages
> from a VM frontend driver to a backend driver.
>
> This patch adds the necessary code
On Wed, May 11, 2016 at 04:33:35PM +0100, Paul Durrant wrote:
> My recent patch to include/xen/interface/io/netif.h defines a new shared
> ring (in addition to the rx and tx rings) for passing control messages
> from a VM frontend driver to a backend driver.
>
> A previous patch added the necessar
My recent patch to include/xen/interface/io/netif.h defines a new extra
info type that can be used to pass hash values between backend and guest
frontend.
This patch adds code to xen-netback to pass hash values calculated for
guest receive-side packets (i.e. netback transmit side) to the frontend.
My recent patch to import an up-to-date include/xen/interface/io/netif.h
from the Xen Project brought in the necessary definitions to support the
new control shared ring and protocol. This patch series updates xen-netback
to support the new ring.
Patch #1 adds the necessary boilerplate to map the
My recent patch to include/xen/interface/io/netif.h defines a new extra
info type that can be used to pass hash values between backend and guest
frontend.
This patch adds code to xen-netback to use the value in a hash extra
info fragment passed from the guest frontend in a transmit-side
(i.e. netb
My recent patch to include/xen/interface/io/netif.h defines a new shared
ring (in addition to the rx and tx rings) for passing control messages
from a VM frontend driver to a backend driver.
A previous patch added the necessary boilerplate for mapping the control
ring from the frontend, should it
My recent patch to include/xen/interface/io/netif.h defines a new extra
info type that can be used to pass hash values between backend and guest
frontend.
This patch adds code to xen-netback to use the value in a hash extra
info fragment passed from the guest frontend in a transmit-side
(i.e. netb
Is that a bug or does #ve info page can only exist on dom0? If this is
true, why would there be a is_hvm_domain check which will stop the
execution of xc_altp2m_vcpu_enable_notify?
2016-05-11 15:56 GMT+08:00 Big Strong :
> From what I analyzed, can I draw a concolusion that the current
> implemen
My recent patch to include/xen/interface/io/netif.h defines a new extra
info type that can be used to pass hash values between backend and guest
frontend.
This patch adds code to xen-netback to pass hash values calculated for
guest receive-side packets (i.e. netback transmit side) to the frontend.
My recent patch to include/xen/interface/io/netif.h defines a new shared
ring (in addition to the rx and tx rings) for passing control messages
from a VM frontend driver to a backend driver.
This patch adds the necessary code to xen-netback to map this new shared
ring, should it be created by a fr
My recent patch to include/xen/interface/io/netif.h defines a new shared
ring (in addition to the rx and tx rings) for passing control messages
from a VM frontend driver to a backend driver.
This patch adds the necessary code to xen-netback to map this new shared
ring, should it be created by a fr
My recent patch to import an up-to-date include/xen/interface/io/netif.h
from the Xen Project brought in the necessary definitions to support the
new control shared ring and protocol. This patch series updates xen-netback
to support the new ring.
Patch #1 adds the necessary boilerplate to map the
My recent patch to include/xen/interface/io/netif.h defines a new shared
ring (in addition to the rx and tx rings) for passing control messages
from a VM frontend driver to a backend driver.
A previous patch added the necessary boilerplate for mapping the control
ring from the frontend, should it
flight 94000 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94000/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 7 host-ping-check-xen fail REGR. vs. 93932
Regressions which
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 11 May 2016 16:16
> To: xen-de...@lists.xenproject.org; net...@vger.kernel.org
> Cc: Paul Durrant; Wei Liu
> Subject: [PATCH net-next v2 2/4] xen-netback: add control protocol
> implementation
>
> My recent
No functional change:
-Various coding style fix
-Added comments for UPDATE_LIMIT_SHIFT.
Use non-atomic bit-ops:
-Vcpu flags are checked and cleared atomically. Performance can be
improved with corresponding non-atomic versions since schedule.c
already has spin_locks in place.
Suggested-by:
On 05/11/2016 03:05 PM, Juergen Gross wrote:
On 11/05/16 15:07, Arnd Bergmann wrote:
A bugfix patch for the xen balloon driver introduced a forward
declaration for a static function that is conditionally compiled,
causing a warning if only the declaration but not the definition
are there:
drive
Hello,
http://bugs.xenproject.org/xen/bug/26 is nearly 3yrs old.
(bassically one can attach the same vbd rw to 2 domUs with xl without
warning )
Combined with a distribution behavior like
https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1572446
(a trailing domu.cfg~ backup file will be
On Wed, May 11, George Dunlap wrote:
> At the moment, the xendomains init script will only create a lockfile
> if when started, it actually does something -- either tries to restore
> a previously saved domain as a result of XENDOMAINS_RESTORE, or tries
> to create a domain as a result of XENDOMAI
On Wed, May 11, George Dunlap wrote:
> Commit c996572 changed the LOCKFILE path from a check between two
> hardcoded paths (/var/lock/subsys/ or /var/lock) to using the
> XEN_LOCK_DIR variable designated at configure time. Since
> XEN_LOCK_DIR doesn't (and shouldn't) have the 'subsys' postfix, th
On 11/05/16 14:59, Konrad Rzeszutek Wilk wrote:
> If we have to abort in xsplice_spin() we end following
> the goto abort. But unfortunataly we neglected to unmask.
> This patch fixes that.
>
> Reported-by: Martin Pohlack
> Signed-off-by: Konrad Rzeszutek Wilk
Reviewed-by: Andrew Cooper
__
On Wed, May 11, 2016 at 12:14:45PM +0100, George Dunlap wrote:
> At the moment, the xendomains init script will only create a lockfile
> if when started, it actually does something -- either tries to restore
> a previously saved domain as a result of XENDOMAINS_RESTORE, or tries
> to create a domai
On Wed, May 11, 2016 at 12:19:45PM +0100, George Dunlap wrote:
> On 11/05/16 12:14, George Dunlap wrote:
> > At the moment, the xendomains init script will only create a lockfile
> > if when started, it actually does something -- either tries to restore
> > a previously saved domain as a result of
On Wed, May 11, 2016 at 12:14:44PM +0100, George Dunlap wrote:
> Commit c996572 changed the LOCKFILE path from a check between two
> hardcoded paths (/var/lock/subsys/ or /var/lock) to using the
> XEN_LOCK_DIR variable designated at configure time. Since
> XEN_LOCK_DIR doesn't (and shouldn't) have
On 11/05/16 15:07, Arnd Bergmann wrote:
> A bugfix patch for the xen balloon driver introduced a forward
> declaration for a static function that is conditionally compiled,
> causing a warning if only the declaration but not the definition
> are there:
>
> drivers/xen/balloon.c:154:13: error: 'rel
On Wed, May 11, 2016 at 09:59:08AM -0400, Konrad Rzeszutek Wilk wrote:
> If we have to abort in xsplice_spin() we end following
> the goto abort. But unfortunataly we neglected to unmask.
> This patch fixes that.
>
> Reported-by: Martin Pohlack
> Signed-off-by: Konrad Rzeszutek Wilk
>
Reviewed
On Wed, May 11, 2016 at 02:44:19PM +0100, Wei Liu wrote:
> On Wed, May 11, 2016 at 04:00:39AM -0600, Jan Beulich wrote:
> > >>> On 02.05.16 at 12:16, wrote:
> > > On Fri, Apr 22, 2016 at 02:44:25AM -0600, Jan Beulich wrote:
> > >> Short of getting any feedback on the previous discussion item
> > >
If we have to abort in xsplice_spin() we end following
the goto abort. But unfortunataly we neglected to unmask.
This patch fixes that.
Reported-by: Martin Pohlack
Signed-off-by: Konrad Rzeszutek Wilk
---
Cc: jbeul...@suse.com
Cc:
This has been since v6 posting. v5 posting used the
set_nmi_ca
On Wed, May 11, 2016 at 11:51:53AM +0200, Martin Pohlack wrote:
> On 27.04.2016 05:39, Konrad Rzeszutek Wilk wrote:
> [...]
> > +/* "Mask" NMIs. */
> > +arch_xsplice_mask();
>
> You mask here ...
>
> > +barrier(); /* MUST do it after get_cpu_maps. */
> > +cpus = nu
On 06/05/16 13:41, Juergen Gross wrote:
> Looking at the qdisk backend implementation I wondered whether
> blkif_get_x86_32_req() is really correct, especially for the
> BLKIF_OP_DISCARD case. The Linux kernel based blk backend seems to
> distinguish 32- and 64-bit layouts of blkif_request_discard
This run is configured for baseline tests only.
flight 44405 qemu-upstream-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44405/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm 4 ca
During Xen boot I am seeing the panic in the subject line from
.../xen/drivers/passthrough/vgt/qinval.c
From the Fault Status Register (= 0x40 (ITE)). I am seeing a hardware timeout
on the invalidate
Disabling queued invalidation is not an option. I need to find out why the
operation is timin
On Wed, May 11, 2016 at 04:00:39AM -0600, Jan Beulich wrote:
> >>> On 02.05.16 at 12:16, wrote:
> > On Fri, Apr 22, 2016 at 02:44:25AM -0600, Jan Beulich wrote:
> >> Short of getting any feedback on the previous discussion item
> >> http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg00
On 2016年05月11日 20:27, Matt Fleming wrote:
> On Fri, 06 May, at 04:32:06PM, Shannon Zhao wrote:
>> > From: Shannon Zhao
>> >
>> > Add a new function to parse DT parameters for Xen specific UEFI just
>> > like the way for normal UEFI. Then it could reuse the existing codes.
>> >
>> > If Xen suppor
On 11/05/16 14:48, David Vrabel wrote:
> On 11/05/16 13:21, Jan Beulich wrote:
> On 11.05.16 at 12:16, wrote:
>>> On 11/05/16 08:00, Juergen Gross wrote:
Adding David as he removed _PAGE_IOMAP in kernel 3.18.
>>>
>>> Why don't we get the RW bits correct when making the pteval when we
>>>
>>> On 11.05.16 at 14:48, wrote:
> On 11/05/16 13:21, Jan Beulich wrote:
> On 11.05.16 at 12:16, wrote:
>>> On 11/05/16 08:00, Juergen Gross wrote:
Adding David as he removed _PAGE_IOMAP in kernel 3.18.
>>>
>>> Why don't we get the RW bits correct when making the pteval when we
>>> alrea
A bugfix patch for the xen balloon driver introduced a forward
declaration for a static function that is conditionally compiled,
causing a warning if only the declaration but not the definition
are there:
drivers/xen/balloon.c:154:13: error: 'release_memory_resource' declared
'static' but never d
On Wed, May 11, Olaf Hering wrote:
> Migration from staging-4.4 to staging-4.6 fails in the same way. We did
> not have a 4.6 based Xen, so noone noticed until now.
And migration from staging-4.5 to staging works as well. So this leaves
staging-4.4.
Olaf
flight 94028 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94028/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
flight 93989 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93989/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-libvirt 14 guest-saverestore fail in 93928 pass in 93989
test-armhf-armhf-xl 15 guest-
The XEN UEFI code has become available on the ARM architecture
recently, but now causes a link-time warning:
ld: warning: drivers/xen/efi.o uses 2-byte wchar_t yet the output is to use
4-byte wchar_t; use of wchar_t values across objects may fail
This seems harmless, because the efi code only us
On 11/05/16 13:21, Jan Beulich wrote:
On 11.05.16 at 12:16, wrote:
>> On 11/05/16 08:00, Juergen Gross wrote:
>>> Adding David as he removed _PAGE_IOMAP in kernel 3.18.
>>
>> Why don't we get the RW bits correct when making the pteval when we
>> already have the pfn, instead trying to fix it
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 11 May 2016 13:23
> To: Olaf Hering; xen-devel@lists.xen.org; Paul Durrant
> Subject: Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq
> server
>
> On 11/05/16 13:18, Olaf Hering wrote:
>
On Wed, May 11, Andrew Cooper wrote:
> On 11/05/16 13:18, Olaf Hering wrote:
> > Migrating a HVM guest from staging-4.4 to staging fails:
> >
> > # cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-clean--incoming.log
> > char device redirected to /dev/pts/3 (label serial0)
> > xen: ioreq server create: C
On Fri, 06 May, at 09:52:42AM, Mathieu Poirier wrote:
> > +static int __init efi_remap_init(void)
> > +{
> > + u64 mapsize;
> > +
> > + pr_info("Remapping and enabling EFI services.\n");
> > +
> > + mapsize = memmap.map_end - memmap.map;
> > + memmap.map = (__force void *)io
On Fri, 06 May, at 04:32:06PM, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Add a new function to parse DT parameters for Xen specific UEFI just
> like the way for normal UEFI. Then it could reuse the existing codes.
>
> If Xen supports EFI, initialize runtime services.
This commit log would b
On 11/05/16 13:18, Olaf Hering wrote:
> Migrating a HVM guest from staging-4.4 to staging fails:
>
> # cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-clean--incoming.log
> char device redirected to /dev/pts/3 (label serial0)
> xen: ioreq server create: Cannot allocate memory
> qemu-system-x86_64: xen ha
>>> On 11.05.16 at 12:16, wrote:
> On 11/05/16 08:00, Juergen Gross wrote:
>> Adding David as he removed _PAGE_IOMAP in kernel 3.18.
>
> Why don't we get the RW bits correct when making the pteval when we
> already have the pfn, instead trying to fix it up afterwards.
While it looks like this wo
Migrating a HVM guest from staging-4.4 to staging fails:
# cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-clean--incoming.log
char device redirected to /dev/pts/3 (label serial0)
xen: ioreq server create: Cannot allocate memory
qemu-system-x86_64: xen hardware virtual machine initialisation failed
Loo
>>> On 11.05.16 at 12:10, wrote:
> On 11/05/16 12:03, Jan Beulich wrote:
> On 11.05.16 at 11:57, wrote:
>>> On 11/05/16 09:15, Jan Beulich wrote:
>>> On 11.05.16 at 09:00, wrote:
> Having a Xen specific pte flag seems to be much more intrusive than
> having an early boot page fau
On 11/05/16 12:14, George Dunlap wrote:
> At the moment, the xendomains init script will only create a lockfile
> if when started, it actually does something -- either tries to restore
> a previously saved domain as a result of XENDOMAINS_RESTORE, or tries
> to create a domain as a result of XENDOM
At the moment, the xendomains init script will only create a lockfile
if when started, it actually does something -- either tries to restore
a previously saved domain as a result of XENDOMAINS_RESTORE, or tries
to create a domain as a result of XENDOMAINS_AUTO.
RedHat-based SYSV init systems try t
Commit c996572 changed the LOCKFILE path from a check between two
hardcoded paths (/var/lock/subsys/ or /var/lock) to using the
XEN_LOCK_DIR variable designated at configure time. Since
XEN_LOCK_DIR doesn't (and shouldn't) have the 'subsys' postfix, this
effectively moves all the lock files by def
Dear Community members,
Yesterday, we created Xen 4.7 RC2 and will release a new release
candidate every Wednesday, until we declare a release candidate as the
final candidate and cut the Xen 4.7 release. We will also hold a Test
Day [1] every Friday for the release candidate that was released
flight 94026 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94026/
Perfect :-)
All tests in this flight passed
version targeted for testing:
xen c79fc6c4bee28b40948838a760b4aaadf6b5cd47
baseline version:
xen f8c66c2ad2efdb281e
On Wed, May 11, 2016 at 10:36:28AM +0200, Juergen Gross wrote:
> On 10/05/16 18:21, Anthony PERARD wrote:
> > On Fri, May 06, 2016 at 11:42:45AM +0200, Juergen Gross wrote:
> >> -static int xen_config_dev_mkdir(char *dev, int p)
> >> -{
> >> -struct xs_permissions perms[2] = {{
> >> -
On Fri, May 06, 2016 at 11:42:46AM +0200, Juergen Gross wrote:
> Add a backend for para-virtualized USB devices for xen domains.
>
> The backend is using host-libusb to forward USB requests from a
> domain via libusb to the real device(s) passed through.
>
> Signed-off-by: Juergen Gross
Acked-b
flight 94022 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94022/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
On 11/05/16 08:00, Juergen Gross wrote:
> On 11/05/16 08:35, Jan Beulich wrote:
> On 11.05.16 at 07:49, wrote:
>>> On 10/05/16 18:35, Boris Ostrovsky wrote:
On 05/10/2016 11:43 AM, Juergen Gross wrote:
> On 10/05/16 17:35, Jan Beulich wrote:
> On 10.05.16 at 17:19, wrote:
>>>
On 11/05/16 12:03, Jan Beulich wrote:
On 11.05.16 at 11:57, wrote:
>> On 11/05/16 09:15, Jan Beulich wrote:
>> On 11.05.16 at 09:00, wrote:
Having a Xen specific pte flag seems to be much more intrusive than
having an early boot page fault handler consisting of just one line
>>
On Wed, May 11, 2016 at 11:03:06AM +0100, Julien Grall wrote:
>
>
>On 11/05/2016 10:57, Peng Fan wrote:
>>Hi Julien,
>
>Hi Peng,
>
>>On Wed, May 11, 2016 at 10:31:49AM +0100, Julien Grall wrote:
>>>
>>>[...]
>>>
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 94ea054..bebd82f 10064
>>> On 11.05.16 at 11:57, wrote:
> On 11/05/16 09:15, Jan Beulich wrote:
> On 11.05.16 at 09:00, wrote:
>>> Having a Xen specific pte flag seems to be much more intrusive than
>>> having an early boot page fault handler consisting of just one line
>>> being capable to mimic the default handle
On 11/05/2016 10:57, Peng Fan wrote:
Hi Julien,
Hi Peng,
On Wed, May 11, 2016 at 10:31:49AM +0100, Julien Grall wrote:
[...]
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 94ea054..bebd82f 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -443,12 +443,6 @@ void __init
>>> On 02.05.16 at 12:16, wrote:
> On Fri, Apr 22, 2016 at 02:44:25AM -0600, Jan Beulich wrote:
>> Short of getting any feedback on the previous discussion item
>> http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg00571.html
>> here's a formal revert request: Please revert commit 19f
On 11/05/16 09:15, Jan Beulich wrote:
On 11.05.16 at 09:00, wrote:
>> Having a Xen specific pte flag seems to be much more intrusive than
>> having an early boot page fault handler consisting of just one line
>> being capable to mimic the default handler in just one aspect (see
>> attached pa
Hi Julien,
On Wed, May 11, 2016 at 10:31:49AM +0100, Julien Grall wrote:
>Hi Peng,
>
>I would rename the title: "xen/arm: mm: remove unnecessary tlb flush in
>setup_pagetables".
Thanks. Will fix in V2.
>
>On 11/05/2016 08:59, Peng Fan wrote:
>>Before relocating xen to high address, need to build
On 27.04.2016 05:39, Konrad Rzeszutek Wilk wrote:
[...]
> +/* "Mask" NMIs. */
> +arch_xsplice_mask();
You mask here ...
> +barrier(); /* MUST do it after get_cpu_maps. */
> +cpus = num_online_cpus() - 1;
> +
> +if ( cpus )
> +{
> +dprint
>>> On 10.05.16 at 23:05, wrote:
> Convert the 'perfc' and 'perfc_arrays' options to Kconfig as
> CONFIG_PERF_COUNTERS and CONFIG_PERF_ARRAYS to minimize code changes.
I don't understand the "to minimize code changes" part.
> @@ -12,18 +10,15 @@ lto ?= n
>
> include $(XEN_ROOT)/Conf
>>> On 10.05.16 at 23:05, wrote:
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -1,6 +1,13 @@
>
> menu "Debugging Options"
>
> +config CRASH_DEBUG
> + bool "Crash Debugging Support"
> + depends on X86
> + ---help---
> + If you want to be able to attach gdb to Xen t
This run is configured for baseline tests only.
flight 44403 qemu-upstream-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44403/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 4 captu
>>> On 10.05.16 at 23:05, wrote:
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -15,4 +15,11 @@ config DEBUG
> option is intended for development purposes only, and not for
> production use.
>
> +config VERBOSE_DEBUG
> + bool "Verbose debug messages"
> + default
1 - 100 of 122 matches
Mail list logo
