>>> On 15.04.16 at 14:33, wrote:
> Existing solution does not allocate space for this symbol and any
> references to acpi20, etc. does not make sense. As I saw any efi.*
> references are protected by relevant ifs but we should not do that
> because it makes code very fragile. If somebody does not
>>> On 15.04.16 at 14:33, wrote:
> --- a/xen/arch/x86/efi/stub.c
> +++ b/xen/arch/x86/efi/stub.c
> @@ -4,11 +4,8 @@
> #include
> #include
>
> -#ifndef efi_enabled
> -const bool_t efi_enabled = 0;
> -#endif
> -
> struct efi __read_mostly efi = {
> + .flags = 0, /* Initialized later. */
>>> On 15.04.16 at 14:33, wrote:
> --- a/xen/arch/x86/efi/Makefile
> +++ b/xen/arch/x86/efi/Makefile
> @@ -1,14 +1,9 @@
> CFLAGS += -fshort-wchar
>
> -obj-y += stub.o
> -
> -create = test -e $(1) || touch -t 19990101 $(1)
> -
> efi := y$(shell rm -f disabled)
> efi := $(if $(efi),$(shell
On May 23, 2016 11:43 PM, Jan Beulich wrote:
> >>> On 23.05.16 at 17:22, wrote:
> > On May 23, 2016 9:31 PM, Jan Beulich wrote:
> >> >>> On 18.05.16 at 10:08, wrote:
> >> > --- a/xen/drivers/passthrough/vtd/iommu.c
> >> > +++ b/xen/drivers/passthrough/vtd/iommu.c
> >> > @@ -557,14 +557,16 @@ st
>>> On 25.05.16 at 08:41, wrote:
> On May 24, 2016 4:22 PM, Jan Beulich wrote:
>> >>> On 18.05.16 at 10:08, wrote:
>> > static int device_power_down(void)
>> > {
>> > -console_suspend();
>> > +if ( console_suspend() )
>> > +return SAVED_CONSOLE;
>>
>> I said so on the previous
>>> On 25.05.16 at 10:04, wrote:
> On May 23, 2016 11:43 PM, Jan Beulich wrote:
>> >>> On 23.05.16 at 17:22, wrote:
>> > On May 23, 2016 9:31 PM, Jan Beulich wrote:
>> >> >>> On 18.05.16 at 10:08, wrote:
>> >> > --- a/xen/drivers/passthrough/vtd/iommu.c
>> >> > +++ b/xen/drivers/passthrough/vt
>>> On 15.04.16 at 14:33, wrote:
> There is a problem with place_string() which is used as early memory
> allocator. It gets memory chunks starting from start symbol and
> going down. Sadly this does not work when Xen is loaded using multiboot2
> protocol because start lives on 1 MiB address. So,
On May 25, 2016 4:30 PM, Jan Beulich wrote:
> >>> On 25.05.16 at 10:04, wrote:
> > On May 23, 2016 11:43 PM, Jan Beulich wrote:
> >> >>> On 23.05.16 at 17:22, wrote:
> >> > On May 23, 2016 9:31 PM, Jan Beulich wrote:
> >> >> >>> On 18.05.16 at 10:08, wrote:
> >> >> > --- a/xen/drivers/passthr
flight 94753 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94753/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 94748
version targeted
On Mon, 23 May 2016, Julien Grall wrote:
> Note, that XENMAPSPACE_dev_mmio has been introduced in Xen 4.7 (which is due
> in a couple of weeks) and part of the stable ABI. So if it is not possible to
> relax the memory attribute, it might be worth to think fixing/reverting the
> hypercall for 4.7.
>>> On 15.04.16 at 14:33, wrote:
> @@ -100,19 +107,29 @@ multiboot2_header_end:
> gdt_boot_descr:
> .word 6*8-1
> .long sym_phys(trampoline_gdt)
> +.long 0 /* Needed for 64-bit lgdt */
> +
> +cs32_switch_addr:
> +.long sym_phys(cs32_switch)
> +.wo
On 24/05/16 23:48, Andy Lutomirski wrote:
> In aa1acff356bb ("x86/xen: Probe target addresses in
> set_aliased_prot() before the hypercall"), I added an explicit probe
> to work around a hypercall issue. The code can be simplified by
> using probe_kernel_read.
>
> Cc: Andrew Cooper
> Cc: Boris Os
On Tue, 24 May 2016, Julien Grall wrote:
> On 23/05/2016 16:42, Edgar E. Iglesias wrote:
> > On Mon, May 23, 2016 at 04:13:53PM +0100, Julien Grall wrote:
> > > On 23/05/16 15:02, Edgar E. Iglesias wrote:
> > > > On Mon, May 23, 2016 at 02:02:39PM +0100, Julien Grall wrote:
> > > > > (CC Wei Liu)
>
flight 94754 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94754/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 3 host-install(3) broken REG
On 24/05/16 23:48, Andy Lutomirski wrote:
> In aa1acff356bb ("x86/xen: Probe target addresses in
> set_aliased_prot() before the hypercall"), I added an explicit probe
> to work around a hypercall issue. The code can be simplified by
> using probe_kernel_read.
Acked-by: David Vrabel
David
Hi Stefano,
On 25/05/16 10:43, Stefano Stabellini wrote:
For SRAM it would be normal memory uncached (?) when the property
"no-memory-wc" is not present, else TBD.
I suspect we would have to relax more MMIOs in the future. Rather than
providing a function to map, the code is very similar except
On Wed, 25 May 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 25/05/16 10:43, Stefano Stabellini wrote:
> > > For SRAM it would be normal memory uncached (?) when the property
> > > "no-memory-wc" is not present, else TBD.
> > >
> > > I suspect we would have to relax more MMIOs in the future. Rat
On Tue, May 24, 2016 at 06:50:23PM +0100, Wei Liu wrote:
> On Sun, May 22, 2016 at 05:37:51AM +, osstest service owner wrote:
> > branch xen-unstable
> > xenbranch xen-unstable
> > job test-amd64-amd64-xl-qemuu-ovmf-amd64
> > testid guest-start/debianhvm.repeat
> >
> > Tree: linux git://xenbit
On Wed, May 25, 2016 at 06:28:43AM +, osstest service owner wrote:
> flight 94746 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/94746/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-armhf-ar
On Wed, May 25, 2016 at 11:10:21AM +0100, Wei Liu wrote:
> On Tue, May 24, 2016 at 06:50:23PM +0100, Wei Liu wrote:
> > On Sun, May 22, 2016 at 05:37:51AM +, osstest service owner wrote:
> > > branch xen-unstable
> > > xenbranch xen-unstable
> > > job test-amd64-amd64-xl-qemuu-ovmf-amd64
> > >
>>> On 25.05.16 at 11:32, wrote:
On 15.04.16 at 14:33, wrote:
>> @@ -221,6 +372,13 @@ trampoline_setup:
>> add $12,%esp/* Remove reloc() args from stack. */
>> mov %eax,sym_phys(multiboot_ptr)
>>
>> +/*
>> + * Do not zero BSS on EFI pla
>>> On 15.04.16 at 14:33, wrote:
> --- a/xen/arch/x86/boot/build32.lds
> +++ b/xen/arch/x86/boot/build32.lds
> @@ -25,6 +25,7 @@ SECTIONS
> *(.text)
> *(.text.*)
> *(.rodata)
> +*(.rodata.*)
>}
Interesting - didn't you say you don't want this for now?
> ---
On Tue, May 24, 2016 at 08:44:41PM +0100, Julien Grall wrote:
> Hi Edgar,
Hi Julien,
>
> On 23/05/2016 16:42, Edgar E. Iglesias wrote:
> >On Mon, May 23, 2016 at 04:13:53PM +0100, Julien Grall wrote:
> >>On 23/05/16 15:02, Edgar E. Iglesias wrote:
> >>>On Mon, May 23, 2016 at 02:02:39PM +0100, J
Signed-off-by: Wei Liu
---
make-flight | 1 +
1 file changed, 1 insertion(+)
diff --git a/make-flight b/make-flight
index f324f6a..18e5bc3 100755
--- a/make-flight
+++ b/make-flight
@@ -122,6 +122,7 @@ job_create_test_filter_callback () {
*) return 1;;
esac
case $job in
>>> On 15.04.16 at 14:33, wrote:
> Every multiboot protocol (regardless of version) compatible image must
> specify its load address (in ELF or multiboot header). Multiboot protocol
> compatible loader have to load image at specified address. However, there
> is no guarantee that the requested mem
On Tue, May 24, 2016 at 04:47:38PM -0400, Meng Xu wrote:
> Hi Olaf,
>
> Thank you very much for your suggestion!
>
> On Fri, May 20, 2016 at 4:52 AM, Olaf Hering wrote:
> > On Thu, May 19, Meng Xu wrote:
> >
> >> Does anyone try to install two version of Xen toolstack on the same
> >> machine?
flight 94759 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94759/
Perfect :-)
All tests in this flight passed
version targeted for testing:
xen 4504b7d1a6594c8ad4b1ecdab15d30feca7eaa51
baseline version:
xen ed2cddb66b40cacdef
>>> On 15.04.16 at 14:33, wrote:
> Add multiboot2 protocol support for relocatable images. Only GRUB2 with
> "multiboot2: Add support for relocatable images" patch understands
> that feature. Older multiboot protocol (regardless of version)
> compatible loaders ignore it and everything works as us
On Tue, May 24, 2016 at 11:29 PM, Ingo Molnar wrote:
> Do they apply, build and boot cleanly in that order on top of v4.4, v4.5 and
> v4.6?
> If yes then:
>
> Acked-by: Ingo Molnar
I confirm that they do so on top of v4.4.
Acked-by: Ed Swierk
___
(Move the thread to Xen-devel)
On 26/05/16 02:47, Chenxiao Zhao wrote:
On 5/25/2016 2:37 AM, Julien Grall wrote:
[...]
root@linaro-alip:~# (XEN) *** Serial input -> Xen (type 'CTRL-x' three
times to
switch input to DOM0)
(XEN) 'd' pressed -> dumping registers
(XEN)
(XEN) *** Dumping CPU0 hos
On Fri, Apr 29, 2016 at 6:42 PM, Tamas K Lengyel wrote:
> Don't propagate altp2m changes from ept_set_entry for memshare as memshare
> already has the lock. We call altp2m propagate changes once memshare
> successfully finishes. Allow the hostp2m entries to be of type
> p2m_ram_shared when applyin
Currently, XENMAPSPACE_dev_mmio maps MMIO regions using one of the most
restrictive memory attribute (Device_nGnRE).
Signed-off-by: Julien Grall
---
xen/include/public/memory.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/xen/include/public/memory.h b/xen/include/publi
Hello all,
This series is based on the thread [1]. To allow future extension, the new
space dev_mmio should have all unused fields marked as reserved.
The first patch enforces the value of the field 'foreign_id'. The second
document the behavior of dev_mmio for ARM.
This series is candidate for
The field 'foreign_id' is not used when the space is dev_mmio. As the
space is not yet part of the stable ABI, the field is marked as reserved
for future use.
The value should always be 0, other values will return -ENOSYS.
Note that the code would need some rework (such as renaming the field
'for
Sorry I forgot to put a proper title.
On 25/05/16 12:41, Julien Grall wrote:
Hello all,
This series is based on the thread [1]. To allow future extension, the new
space dev_mmio should have all unused fields marked as reserved.
The first patch enforces the value of the field 'foreign_id'. The
On 25/05/16 12:24, Julien Grall wrote:
(Move the thread to Xen-devel)
On 26/05/16 02:47, Chenxiao Zhao wrote:
On 5/25/2016 2:37 AM, Julien Grall wrote:
[...]
root@linaro-alip:~# (XEN) *** Serial input -> Xen (type 'CTRL-x' three
times to
switch input to DOM0)
(XEN) 'd' pressed -> dumping
On 05/24/2016 11:09 AM, Christoph Hellwig wrote:
> I think this is moving into the wrong direction. The right fix here
> is to get of all the dma_attrs boilerplate code and just replace it
> with a simple enum dma_flags. This would simplify both the callers
> and most importantly the wrappers for
Hi Wei,
On Wed, May 25, 2016 at 10:10:11AM +0800, Wei Chen wrote:
>In ARM64, the MPIDR multiprocessing extensions bit is reserved to 1.
>So, the value check for this bit is no longer necessary on ARM64.
From ARM DDI0487A.G, I found the U bit for MPIDR_EL1:
"
Indicates a Uniprocessor system, as di
> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Tuesday, May 24, 2016 10:02 PM
> To: Wu, Feng ; Jan Beulich
> Cc: andrew.coop...@citrix.com; george.dun...@eu.citrix.com; Tian, Kevin
> ; xen-devel@lists.xen.org; konrad.w...@oracle.com;
> k...@xen.org
On Wed, May 11, 2016 at 12:14 PM, 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 's
On Wed, May 11, 2016 at 12:14 PM, 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
>>> On 25.05.16 at 13:41, wrote:
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1143,6 +1143,10 @@ int xenmem_add_to_physmap_one(
> break;
> }
> case XENMAPSPACE_dev_mmio:
> +/* The field 'foreign_domid' is reserved for future use */
> +if ( foreign_do
>>> On 25.05.16 at 13:41, wrote:
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -220,7 +220,10 @@ DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
> #define XENMAPSPACE_gmfn_range 3 /* GMFN range, XENMEM_add_to_physmap
> only. */
> #define XENMAPSPACE_gmfn_foreig
The commit 2aa925be84293b44ad587ed117184ace61b41dd6 "arm/x86: Use struct
virtual_region to do bug, symbol, and (x86) exception tables lookup."
has introduced virtual_region. The call to initialize those regions is
made in init_traps which is called during each CPU bring up.
This will result to reg
This ensures buf is always valid when it is passed to strtok_r.
CID: 1291936
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
This is a backport candidate.
---
tools/libxl/xl_cmdimpl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdi
Wei Liu writes ("[PATCH OSSTEST] make-flight: don't create ovmf tests for
seabios branch"):
> Signed-off-by: Wei Liu
Acked-by: Ian Jackson
I have queued this in a branch that will see it pushed at some point.
Thanks,
Ian.
___
Xen-devel mailing list
> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Tuesday, May 24, 2016 10:47 PM
> To: Wu, Feng ; Jan Beulich
> Cc: andrew.coop...@citrix.com; george.dun...@eu.citrix.com; Tian, Kevin
> ; xen-devel@lists.xen.org; konrad.w...@oracle.com;
> k...@xen.org
Should be "multiple times" in title.
On Wed, May 25, 2016 at 02:14:06PM +0100, Julien Grall wrote:
> The commit 2aa925be84293b44ad587ed117184ace61b41dd6 "arm/x86: Use struct
> virtual_region to do bug, symbol, and (x86) exception tables lookup."
> has introduced virtual_region. The call to initial
Hello Peng,
On 25/05/16 13:37, Peng Fan wrote:
On Wed, May 25, 2016 at 10:10:11AM +0800, Wei Chen wrote:
In ARM64, the MPIDR multiprocessing extensions bit is reserved to 1.
So, the value check for this bit is no longer necessary on ARM64.
From ARM DDI0487A.G, I found the U bit for MPIDR_EL1
On Tue, May 24, 2016 at 08:44:41PM +0100, Julien Grall wrote:
> Hi Edgar,
>
> On 23/05/2016 16:42, Edgar E. Iglesias wrote:
> >On Mon, May 23, 2016 at 04:13:53PM +0100, Julien Grall wrote:
> >>On 23/05/16 15:02, Edgar E. Iglesias wrote:
> >>>On Mon, May 23, 2016 at 02:02:39PM +0100, Julien Grall w
On 25/05/16 14:23, Wei Liu wrote:
> This ensures buf is always valid when it is passed to strtok_r.
>
> CID: 1291936
>
> Signed-off-by: Wei Liu
> ---
> Cc: Ian Jackson
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http
Wei Liu writes ("[PATCH for-4.7] xl: use xstrdup in cpurange_parse"):
> This ensures buf is always valid when it is passed to strtok_r.
>
> CID: 1291936
>
> Signed-off-by: Wei Liu
Acked-by: Ian Jackson
> This is a backport candidate.
Really ? malloc failing is vanishingly rare in practice n
On Wed, May 25, 2016 at 02:33:41PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH for-4.7] xl: use xstrdup in cpurange_parse"):
> > This ensures buf is always valid when it is passed to strtok_r.
> >
> > CID: 1291936
> >
> > Signed-off-by: Wei Liu
>
> Acked-by: Ian Jackson
>
> > This is
On Wed, May 25, 2016 at 02:14:06PM +0100, Julien Grall wrote:
> The commit 2aa925be84293b44ad587ed117184ace61b41dd6 "arm/x86: Use struct
> virtual_region to do bug, symbol, and (x86) exception tables lookup."
> has introduced virtual_region. The call to initialize those regions is
> made in init_tr
On Wed, May 25, 2016 at 02:14:06PM +0100, Julien Grall wrote:
> The commit 2aa925be84293b44ad587ed117184ace61b41dd6 "arm/x86: Use struct
> virtual_region to do bug, symbol, and (x86) exception tables lookup."
> has introduced virtual_region. The call to initialize those regions is
> made in init_tr
Hi Wei,
Please try to send all the patches with the cover letter as references.
git send-email should do it if you send all the patches at once.
This is really helpful to with mail client supporting thread.
Regards,
On 25/05/16 03:08, Wei Chen wrote:
In ARM64 the MPIDR register is mapped to
On Wed, May 25, 2016 at 02:23:56PM +0100, Wei Liu wrote:
> This ensures buf is always valid when it is passed to strtok_r.
>
> CID: 1291936
>
> Signed-off-by: Wei Liu
Pushed. Thanks everyone.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://
On Wed, May 25, 2016 at 09:37:09AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, May 25, 2016 at 02:14:06PM +0100, Julien Grall wrote:
> > The commit 2aa925be84293b44ad587ed117184ace61b41dd6 "arm/x86: Use struct
> > virtual_region to do bug, symbol, and (x86) exception tables lookup."
> > has intro
flight 94761 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94761/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 3 host-install(3) broken REG
Hi Wei,
On 25/05/16 03:09, Wei Chen wrote:
The cpu_logical_map is used to store CPU hardware ID from MPIDR_EL1 or
from CPU node of DT. Currently, the cpu_logical_map is using the u32 as
its variable type. It can work properly while Xen is running on ARM32,
because the hardware ID is 32-bits. Whi
Hi Wei,
On 25/05/16 03:09, Wei Chen wrote:
The original affinity shift bits algorithm in AFFINITY_MASK is buggy,
it could not generate correct affinity shift bits of level3.
The macro MPIDR_LEVEL_SHIFT can calculate level3 affinity shift bits
correctly. We use this macro in AFFINITY_MASK to gene
On Mon, May 23, 2016 at 6:09 PM, Xen.org security team wrote:
> RESOLUTION
> ==
>
> Applying the appropriate attached patch resolves this issue.
>
> The patches adopt a simple and rather crude approach which is
> effective at resolving the security issue in the context of a Xen
> device mo
On Wed, May 25, 2016 at 07:12:30AM -0600, Jan Beulich wrote:
> >>> On 25.05.16 at 13:41, wrote:
> > --- a/xen/arch/arm/mm.c
> > +++ b/xen/arch/arm/mm.c
> > @@ -1143,6 +1143,10 @@ int xenmem_add_to_physmap_one(
> > break;
> > }
> > case XENMAPSPACE_dev_mmio:
> > +/* The f
Hi Wei,
Title: "Fix the MPIDR_HWID_MASK value for ARM64".
On 25/05/16 03:09, Wei Chen wrote:
Current MPIDR_HWID_MASK is using the bit definition of ARM32 MPIDR.
s/Current/Currently/
This value is not correct while Xen is running on ARM64.
I think s/while/when/
Now, we add a correct valu
Hi Wei,
On 25/05/16 03:10, Wei Chen wrote:
In ARM64, the MPIDR multiprocessing extensions bit is reserved to 1.
Well, technically the bit is unamed for ARM64. So I would make clear
that the name is from AArch32. Something along:
"The bit 31 (former bit Multiprocessing extensions bit in AArc
On Wed, May 25, 2016 at 03:15:23PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH for-4.7] docs: update xl manpage about
> {block,network}-attach command"):
> > State that only attaching PV interface is supported.
> ...
> > Create a new virtual block device. This will trigger a hotplug even
Wei Liu writes ("[PATCH for-4.7] docs: update xl manpage about
{block,network}-attach command"):
> State that only attaching PV interface is supported.
...
> Create a new virtual block device. This will trigger a hotplug event
> -for the guest.
> +for the guest. Note that only attaching PV block
Hi Edgar,
On 25/05/16 14:29, Edgar E. Iglesias wrote:
On Tue, May 24, 2016 at 08:44:41PM +0100, Julien Grall wrote:
Looking a little closer, the place where the generic list of matches and
attributes doesn't work well is when trying to deal with the no-memory-wc
property available only in mmio-s
Hi Jan,
On 25/05/16 14:12, Jan Beulich wrote:
On 25.05.16 at 13:41, wrote:
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1143,6 +1143,10 @@ int xenmem_add_to_physmap_one(
break;
}
case XENMAPSPACE_dev_mmio:
+/* The field 'foreign_domid' is reserved for futur
Wei Liu writes ("Re: [PATCH for-4.7] docs: update xl manpage about
{block,network}-attach command"):
> On Wed, May 25, 2016 at 03:15:23PM +0100, Ian Jackson wrote:
...
> > But the vdev field specifies more than just the device type. So I
> > think this is wrong.
>
> I guess to make things simple
On Wed, May 25, 2016 at 03:28:50PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH for-4.7] docs: update xl manpage about
> {block,network}-attach command"):
> > On Wed, May 25, 2016 at 03:15:23PM +0100, Ian Jackson wrote:
> ...
> > > But the vdev field specifies more than just the device
Boris Ostrovsky writes ("[PATCH qemu-traditional] ioreq: Support 32-bit
default_ioport_* accesses"):
> Recent changes in ACPICA (specifically, Linux commit 66b1ed5aa8dd ("ACPICA:
> ACPI 2.0, Hardware: Add access_width/bit_offset support for
> acpi_hw_write()") result in guests issuing 32-bit acces
The following lockdep dump occurs whenever I destroy an HVM domain, on
Linux 4.4 Dom0 with CONFIG_XEN_BALLOON=n on recent stable Xen 4.5.
Any clues whether this is a real potential deadlock, or how to silence
it if not?
==
[ INFO: RECLAIM_FS-saf
On Wed, May 25, 2016 at 03:31:19PM +0100, Wei Liu wrote:
> On Wed, May 25, 2016 at 03:28:50PM +0100, Ian Jackson wrote:
> > Wei Liu writes ("Re: [PATCH for-4.7] docs: update xl manpage about
> > {block,network}-attach command"):
> > > On Wed, May 25, 2016 at 03:15:23PM +0100, Ian Jackson wrote:
>
Ian Jackson writes ("Re: [PATCH qemu-traditional] ioreq: Support 32-bit
default_ioport_* accesses"):
> Boris Ostrovsky writes ("[PATCH qemu-traditional] ioreq: Support 32-bit
> default_ioport_* accesses"):
> > Recent changes in ACPICA (specifically, Linux commit 66b1ed5aa8dd ("ACPICA:
> > ACPI 2.
Hi Jan,
On 25/05/16 14:14, Jan Beulich wrote:
On 25.05.16 at 13:41, wrote:
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -220,7 +220,10 @@ DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
#define XENMAPSPACE_gmfn_range 3 /* GMFN range, XENMEM_add_to_physmap only.
flight 94764 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94764/
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 Wed, May 25, 2016 at 03:04:40PM +0100, George Dunlap wrote:
> On Mon, May 23, 2016 at 6:09 PM, Xen.org security team
> wrote:
> > RESOLUTION
> > ==
> >
> > Applying the appropriate attached patch resolves this issue.
> >
> > The patches adopt a simple and rather crude approach which is
>>> On 25.05.16 at 16:43, wrote:
> I could say:
>
> "ARM only; the region will be mapped in Stage-2 using the memory
> attribute 'Device-nGnRE' (previously named 'Device' on ARMv7)".
SGTM
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http:
Correct the number of single byte NOPs we want to be replaced in case
neither SMEP nor SMAP are available.
Also simplify the expression adding these NOPs - at that location .
equals .Lcr4_orig, and removing that part of the expression fixes a
bogus ".space or fill with negative value, ignored" war
On 05/25/2016 10:35 AM, Ian Jackson wrote:
> Ian Jackson writes ("Re: [PATCH qemu-traditional] ioreq: Support 32-bit
> default_ioport_* accesses"):
>> Boris Ostrovsky writes ("[PATCH qemu-traditional] ioreq: Support 32-bit
>> default_ioport_* accesses"):
>>> Recent changes in ACPICA (specifically
On May 25, 2016 4:07 PM, Jan Beulich wrote:
> >>> On 25.05.16 at 08:41, wrote:
> > On May 24, 2016 4:22 PM, Jan Beulich wrote:
> >> >>> On 18.05.16 at 10:08, wrote:
> >> > static int device_power_down(void) {
> >> > -console_suspend();
> >> > +if ( console_suspend() )
> >> > +
Hi Julien,
On 24.05.2016 22:05, Julien Grall wrote:
On 24/05/2016 14:39, Dirk Behme wrote:
Hi Julien,
Hello Dirk,
On 23.05.2016 22:15, Julien Grall wrote:
Hello Dirk,
is there a solution for
arm: domain 0 disables clocks which are in fact being used
http://bugs.xenproject.org/xen/bug/
...along with
https://git.kernel.org/cgit/linux/kernel/git/xen/tip.git/commit/?id=702f9260
which should also go into v4.4, IMO.
On Wed, May 25, 2016 at 4:17 AM, Ed Swierk wrote:
> On Tue, May 24, 2016 at 11:29 PM, Ingo Molnar wrote:
>> Do they apply, build and boot cleanly in that order on top
Boris Ostrovsky writes ("Re: [PATCH qemu-traditional] ioreq: Support 32-bit
default_ioport_* accesses"):
> IIUIC, the Linux/ACPICA patch makes ACPICA use correct field in ACPI's
> Generic Address Structure (section 5.2.3.2 in the 6.0 spec). Before the
> patch it used register's bit_width and now i
On May 23, 2016 10:19 PM, Jan Beulich wrote:
> >>> On 18.05.16 at 10:08, wrote:
>
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -2463,11 +2463,12 @@ static int __put_page_type(struct page_info
> > *page, }
> >
> >
> > -static int __get_page_type(struct page_info *page, unsigned
On May 25, 2016 05:27, "George Dunlap" wrote:
>
> On Fri, Apr 29, 2016 at 6:42 PM, Tamas K Lengyel
wrote:
> > Don't propagate altp2m changes from ept_set_entry for memshare as
memshare
> > already has the lock. We call altp2m propagate changes once memshare
> > successfully finishes. Allow the ho
On 05/25/2016 11:22 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [PATCH qemu-traditional] ioreq: Support 32-bit
> default_ioport_* accesses"):
>> IIUIC, the Linux/ACPICA patch makes ACPICA use correct field in ACPI's
>> Generic Address Structure (section 5.2.3.2 in the 6.0 spec). Before t
On Wed, May 25, 2016 at 03:51:23PM +0100, Wei Liu wrote:
> On Wed, May 25, 2016 at 03:04:40PM +0100, George Dunlap wrote:
> > On Mon, May 23, 2016 at 6:09 PM, Xen.org security team
> > wrote:
> > > RESOLUTION
> > > ==
> > >
> > > Applying the appropriate attached patch resolves this issue
On Mon, May 09, 2016 at 05:31:20PM +0100, Paul Durrant wrote:
> Since Xen will correctly handle accesses to unimplemented I/O ports (by
> returning all 1's for reads and ignoring writes) there is no need for
> QEMU to register backgroud I/O sections.
>
> This patch therefore adds checks to xen_io_
Hello all,
This series is based on the thread [1]. To allow future extension, the new
space dev_mmio should have all unused fields marked as reserved.
This series is candidate for Xen 4.7, the first patch ensure a clean ABI
for the new space which will allow future extension.
See in each patch f
Currently, XENMAPSPACE_dev_mmio maps MMIO regions using one of the most
restrictive memory attribute (Device-nGnRE).
Signed-off-by: Julien Grall
---
Changes in v2:
- s/Device_nGnRE/Device-nGnRE/ to match the spec
- Update the comment to mention the name for ARMv7.
---
xen/in
>>> On 25.05.16 at 17:34, wrote:
> On May 23, 2016 10:19 PM, Jan Beulich wrote:
>> >>> On 18.05.16 at 10:08, wrote:
>> > +unsigned long type,
>> > +int preemptible)
>> > {
>> > unsigned long nx, x, y = page->u.
>>> On 25.05.16 at 17:08, wrote:
> On 05/25/2016 10:35 AM, Ian Jackson wrote:
>> Ian Jackson writes ("Re: [PATCH qemu-traditional] ioreq: Support 32-bit
> default_ioport_* accesses"):
>>> Boris Ostrovsky writes ("[PATCH qemu-traditional] ioreq: Support 32-bit
> default_ioport_* accesses"):
The field 'foreign_id' is not used when the space is dev_mmio. As the
space is not yet part of the stable ABI, the field is marked as reserved
for future use.
The value should always be 0, other values will return -EOPNOTSUPP.
Signed-off-by: Julien Grall
---
Changes in v2:
- Return
On Wed, May 25, 2016 at 09:00:49AM -0600, Jan Beulich wrote:
> Correct the number of single byte NOPs we want to be replaced in case
> neither SMEP nor SMAP are available.
>
> Also simplify the expression adding these NOPs - at that location .
> equals .Lcr4_orig, and removing that part of the exp
>>> On 25.05.16 at 17:36, wrote:
> This is what the spec says:
>
> AccessSize evaluates to an 8-bit integer that specifies the size of data
> values used when accessing the
> address space as follows:
> 0 - Undefined (legacy)
> 1 - Byte access
> 2 - Word access
> 3 - DWord access
> 4 - QWord acce
On Tue, May 24, 2016 at 04:27:18PM +0100, Peter Maydell wrote:
> Clean up includes so that osdep.h is included first and headers
> which it implies are not included manually.
>
> This commit was created with scripts/clean-includes.
>
> Signed-off-by: Peter Maydell
Acked-by: Anthony PERARD
--
On Wed, May 25, 2016 at 4:31 PM, Tamas K Lengyel wrote:
>
> On May 25, 2016 05:27, "George Dunlap" wrote:
>>
>> On Fri, Apr 29, 2016 at 6:42 PM, Tamas K Lengyel
>> wrote:
>> > Don't propagate altp2m changes from ept_set_entry for memshare as
>> > memshare
>> > already has the lock. We call altp2
Jan Beulich writes ("Re: [Xen-devel] [PATCH qemu-traditional] ioreq: Support
32-bit default_ioport_* accesses"):
> On 25.05.16 at 17:36, wrote:
> > AccesSize parameter is optional when invoking the Register macro. If the
> > AccessSize parameter is
> > not supplied then the AccessSize field will
1 - 100 of 145 matches
Mail list logo
