flight 78922 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78922/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken pass in 78815
test-amd64-amd64-xl-qem
Hi,
> > static void igd_passthrough_i440fx_class_init(ObjectClass *klass, void
> > *data)
> > @@ -78,7 +77,7 @@ static void igd_passthrough_i440fx_class_init(ObjectClass
> > *klass, void *data)
> > DeviceClass *dc = DEVICE_CLASS(klass);
> > PCIDeviceClass *k = PCI_DEVICE_CLASS(klass
This run is configured for baseline tests only.
flight 38697 qemu-upstream-unstable running [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38697/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-l
This run is configured for baseline tests only.
flight 38695 xen-4.4-testing running [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38695/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rump
flight 38696 distros-debian-sid running [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38696/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-i386-sid-netboot-pvgrub queued
t
On Fri, 2016-01-22 at 18:04 +0100, Roger Pau Monné wrote:
> El 21/01/16 a les 17.51, Roger Pau Monne ha escrit:
> > Allow enabling or disabling emulated devices from the libxl domain
> > configuration file. For HVM guests with a device model all the emulated
> > devices are enabled. For HVM guests
On Fri, 2016-01-22 at 12:12 -0500, Boris Ostrovsky wrote:
> On 01/15/2016 08:22 AM, Ian Campbell wrote:
> > libxenevtchn will provide a stable API and ABI for accessing the
> > evtchn device.
>
> I think this patch breaks the build:
>
> root@ovs101> gcc -O1 -fno-omit-frame-pointer -m64 -g
> -fn
>>> On 23.01.16 at 01:29, wrote:
> On 01/22/2016 07:02 PM, Jan Beulich wrote:
> On 22.01.16 at 11:40, wrote:
>>> On 01/22/2016 03:53 PM, Jan Beulich wrote:
>>> On 22.01.16 at 04:36, wrote:
> By the way, do you think it's possible to make grant table support bigger
> page e.g 64
On 24/01/16 18:21, Thierry Laurion wrote:
> Hi devs!
>
> XEN devs:
> As per short discussion with ktemkin earlier in January in #xen:
>
> "ktemkin Jan 10, 2016 16:21:50
> This test patch did appear to make the system work, though:
> https://gist.github.com/ktemkin/0e81b93654ae800a5609
>
> ktemkin J
From: Roger Pau Monne
The discussion in [1] lead to an agreement of the missing pieces in PVH
(or HVM without a device-model) in order to progress with it's
implementation.
One of the missing pieces is a new boot ABI, that replaces the PV boot
ABI. The aim of this new boot ABI is to remove the l
El 22/01/16 a les 22.35, Boris Ostrovsky ha escrit:
> HVMlite guests need PCI frontend and always have PV devices
We still haven't discussed how to perform pci-passthrough for HVMlite
guests. I admit there's a big chance that we are going to use the PV
pcifront driver but there's no guarantee abou
On 25/01/16 10:16, Roger Pau Monne wrote:
> From: Roger Pau Monne
>
> The discussion in [1] lead to an agreement of the missing pieces in PVH
> (or HVM without a device-model) in order to progress with it's
> implementation.
>
> One of the missing pieces is a new boot ABI, that replaces the PV boo
El 23/01/16 a les 17.12, Konrad Rzeszutek Wilk ha escrit:
> On January 23, 2016 11:01:06 AM EST, "H. Peter Anvin" wrote:
>> On January 23, 2016 7:34:33 AM PST, Konrad Rzeszutek Wilk
>> wrote:
>>>
However, this stub belongs in Linux, not in the Xen toolstack. That
way, when the Linux bo
On 23/01/16 22:12, Sarah Newman wrote:
> Greetings,
>
> We are having problems related to mptsas and "swiotlb buffer is full" with
> the Xen4CentOS kernel (3.18). It looks like the last related work was
> the series
> http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00770.html
> b
On 22/01/16 21:35, Boris Ostrovsky wrote:
> This series introduces HVMlite support for unprivileged guests.
>
> It has been tested on Intel/AMD, both 32- and 64-bit, including CPU on- and
> offlining and save/restore. (Restore will result in APIC write warnings
> which exist now for 32-bit PV gues
On 22/01/16 21:35, Boris Ostrovsky wrote:
> Xen's HVMlite guests will want to use them.
Please explain in detail why they are needed.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Sat, 23 Jan 2016, Cao jin wrote:
> On 01/22/2016 07:21 PM, Paolo Bonzini wrote:
> >
> >
> > On 21/01/2016 18:01, Stefano Stabellini wrote:
> > > -XEN_PT_LOG(&s->dev, "Failed to initialize %d/%ld
> > > reg 0x%x in grp_type=0x%x (%d/%ld), rc=%d\n",
> > > -
On 22/01/16 21:35, Boris Ostrovsky wrote:
> HVMlite guests (to be introduced in subsequent patches) share most
> of the kernel initialization code with PV(H).
Where possible, HVMlite should share initialization with bare metal/HVM
and not PV(H).
Sharing any code with the existing PVH code isn't u
On 01/19/2016 04:59 PM, Konrad Rzeszutek Wilk wrote:
snip
(And perhaps it should also be in the previous patch since it's mentioned in
the previous patch's changelog?)
I kind of lost where it was added.
I could spin it out as a seperate patch - or make it part of the previous
patch? Thoughts?
>>> On 22.01.16 at 16:51, wrote:
> El 22/01/16 a les 16.31, Jan Beulich ha escrit:
> On 22.01.16 at 15:59, wrote:
>>> If that's the plan, then I think we would also need to fixup the tables
>>> provided to Dom0 in order to match what's available, but that can be
>>> discussed later.
>>
>> I
>>> On 22.01.16 at 18:03, wrote:
> On 22/01/16 14:12, Jan Beulich wrote:
>>
>> And then, how is this supposed to work? You only restore defaults,
>> but never write non-default values. Namely, nextd is an unused
>> function parameter ...
>>
>> Also I guess my comment about addi
On Wed, 2016-01-20 at 15:47 -0600, Doug Goldstein wrote:
> This consolidates some of the different variables used for the ARM
> builds. This change was prompted by the Kconfig changes but looking back
> in time the CONFIG_ARM_{32,64} variables existed before Kconfig so this
> should just be a gener
On Sat, Jan 23, 2016 at 10:35:44AM -0500, Konrad Rzeszutek Wilk wrote:
> On January 23, 2016 9:50:30 AM EST, Wei Liu wrote:
> >On Sat, Jan 23, 2016 at 01:33:40PM +0800, Bob Liu wrote:
> >>
> >> On 01/22/2016 06:50 PM, Wei Liu wrote:
> >> > On Fri, Jan 22, 2016 at 06:45:30PM +0800, Bob Liu wrote:
On 25/01/16 11:29, Wei Liu wrote:
>
> That goes back to the old topic of how to make VirtIO work on Xen (PV in
> particular). It's not easy task by any means.
This is a (very) useful thing to solve anyway so why not go down this
route? Particularly, since the latest discussion had reached a
conc
On 01/19/2016 04:55 PM, Konrad Rzeszutek Wilk wrote:
snip
+/* Must be holding the payload_list lock. */
payload lock?
+static int schedule_work(struct payload *data, uint32_t cmd)
+{
+/* Fail if an operation is already scheduled. */
+if ( xsplice_work.do_work )
+return -EAGAIN
flight 78925 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78925/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs.
66399
test-amd64-i386-qe
On Mon, 25 Jan 2016, Gerd Hoffmann wrote:
> Hi,
>
> > > static void igd_passthrough_i440fx_class_init(ObjectClass *klass, void
> > > *data)
> > > @@ -78,7 +77,7 @@ static void
> > > igd_passthrough_i440fx_class_init(ObjectClass *klass, void *data)
> > > DeviceClass *dc = DEVICE_CLASS(kla
On Sun, 2016-01-24 at 19:45 -0500, Chester Lin wrote:
> To more closely follow the guidelines in CODING_STYLE, store the result
> of xc_sched_id() in the local variable r, and the check the result of
> the call in a separate statement. Change the type of the output
> parameter given to xc_sched_id
On 01/15/2016 04:58 PM, Konrad Rzeszutek Wilk wrote:
Or you can use git://github.com/rosslagerwall/xsplice-build.git tool
(it will need an extra patch, will send that shortly) - which
generates the ELF payloads.
This link has a nice description of how to use the tool:
http://lists.xenproject.org
On Sun, 2016-01-24 at 19:45 -0500, Chester Lin wrote:
> Coverity CID 1343309
>
> Make GC_FREE reachable in all cases in libxl_get_scheduler() by
> eliminating the error-path return and instead storing the error code in
> the returned variable.
>
> To make this semantically consistent, change the
On Fri, Jan 15, Ian Campbell wrote:
> libxenforeignmemory will provide a stable API and ABI for mapping
> foreign domain memory (subject to appropriate privileges).
I think this will break my Xen pkg build:
[ 333s] kdd-xen.c: In function 'kdd_access_physical_page':
[ 333s] kdd-xen.c:508:15: wa
On Sat, 2016-01-23 at 16:00 +0800, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Since we will add ACPI initialization for UART in this file later,
> rename it with a generic name.
>
> Signed-off-by: Shannon Zhao
Acked-by: Ian Campbell
___
Xen-deve
On Fri, 2016-01-22 at 11:50 +, Wei Liu wrote:
> They were added back in 2011 to be used in an adhoc parser which has now
> been removed.
>
> Signed-off-by: Wei Liu
Acked-by: Ian Campbell
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://
On Fri, 2016-01-22 at 08:42 -0700, Jan Beulich wrote:
> When mapping large BARs (e.g. the frame buffer of a graphics card) the
> overhead of establishing such mappings using only 4k pages has,
> particularly after the XSA-125 fix, become unacceptable. Alter the
> XEN_DOMCTL_memory_mapping semantics
On Fri, 2016-01-22 at 11:50 +, Wei Liu wrote:
> No functional changes introduced.
>
> Signed-off-by: Wei Liu
Acked-by: Ian Campbell
(unread)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Sat, 23 Jan 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> ACPI 6.0 introduces a new table STAO to list the devices which are used
> by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> UART is used by Xen. So here it hides UART from Dom0.
>
> Signed-off-by: Shannon
On Fri, 2016-01-22 at 11:50 +, Wei Liu wrote:
> This patch series consolidates adhoc parsers in xl.
>
> There are currently 4 types of devices:
>
> 1. block
> 2. netowrk
> 3. vtpm
> 4. pci
>
> that support hotplug as well as being specified in config file.
>
> Block and pci devices are fine
On Mon, 2016-01-25 at 13:01 +0100, Olaf Hering wrote:
> On Fri, Jan 15, Ian Campbell wrote:
>
> > libxenforeignmemory will provide a stable API and ABI for mapping
> > foreign domain memory (subject to appropriate privileges).
>
> I think this will break my Xen pkg build:
>
> [ 333s] kdd-xen.c:
On Mon, 2016-01-25 at 12:31 +, Ian Campbell wrote:
> On Mon, 2016-01-25 at 13:01 +0100, Olaf Hering wrote:
> > On Fri, Jan 15, Ian Campbell wrote:
> >
> > > libxenforeignmemory will provide a stable API and ABI for mapping
> > > foreign domain memory (subject to appropriate privileges).
> >
>
This:
kdd-xen.c: In function 'kdd_access_physical_page':
kdd-xen.c:508:9: warning: implicit declaration of function
'xc_map_foreign_range' [-Wimplicit-function-declaration]
map = xc_map_foreign_range(g->xc_handle,
^
kdd-xen.c:508:13: warning: assignment makes pointer from intege
"tools/libs/*: Use O_CLOEXEC on Linux and FreeBSD" left some dead code
in the FreeBSD case, which breaks the build on that platform.
Also fix a typo "uint_32".
Signed-off-by: Ian Campbell
---
tools/libs/call/freebsd.c | 8
tools/libs/evtchn/freebsd.c| 2 +-
tools/libs/
We build most of tools using Werror and there seems to be know
deliberate reason for this to be an exception.
Signed-off-by: Ian Campbell
---
tools/debugger/kdd/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/debugger/kdd/Makefile b/tools/debugger/kdd/Makefile
index 72ad1b9..f
On Mon, Jan 25, Ian Campbell wrote:
> We build most of tools using Werror and there seems to be know
> deliberate reason for this to be an exception.
s/know/no/ ?
Acked-by: Olaf Hering
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://
At 12:45 + on 25 Jan (1453725932), Ian Campbell wrote:
> This:
>
> kdd-xen.c: In function 'kdd_access_physical_page':
> kdd-xen.c:508:9: warning: implicit declaration of function
> 'xc_map_foreign_range' [-Wimplicit-function-declaration]
> map = xc_map_foreign_range(g->xc_handle,
>
At 13:18 + on 25 Jan (1453727891), Ian Campbell wrote:
> We build most of tools using Werror and there seems to be know
> deliberate reason for this to be an exception.
>
> Signed-off-by: Ian Campbell
Acked-by: Tim Deegan
___
Xen-devel mailing li
On Mon, 2016-01-25 at 14:20 +0100, Olaf Hering wrote:
> On Mon, Jan 25, Ian Campbell wrote:
>
> > We build most of tools using Werror and there seems to be know
> > deliberate reason for this to be an exception.
>
> s/know/no/ ?
Yes, thanks!
I think I was going to write "I don't know of" and th
On Mon, Jan 25, 2016 at 01:14:34PM +, Ian Campbell wrote:
> "tools/libs/*: Use O_CLOEXEC on Linux and FreeBSD" left some dead code
> in the FreeBSD case, which breaks the build on that platform.
>
> Also fix a typo "uint_32".
>
> Signed-off-by: Ian Campbell
Acked-by: Wei Liu
___
Hi everyone,
I want to bring domain restart question for a discussion. It originates
from DomD restart, but the solution I am about to offer can be quite
generic.
Problem is, domain specification currently holds only frontend info, which
is used to generate both frontend and backend entries for a
>>> On 21.01.16 at 16:14, wrote:
> On Wed, 2016-01-20 at 03:06 -0700, Jan Beulich wrote:
>> > > > On 19.01.16 at 20:55, wrote:
>> >
>> > $ 'addr2line -e xen-syms 82d0801c1cce' returns
>> > 'xen/xen/arch/x86/xstate.c:387' which again points to
>> > xsave. Also, adding 'xsave=0' makes it boot
>>> On 25.01.16 at 13:16, wrote:
> On Fri, 2016-01-22 at 08:42 -0700, Jan Beulich wrote:
>> +#define MAP_MMIO_MAX_ITER 64 /* pretty arbitrary */
>> +
>
> I suppose no existing in-tree code exceeds that (or there'd be more patch
> here).
There simply is no in-tree user other than the domctl on x8
On Sat, 23 Jan 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Use page_to_xen_pfn in case of 64KB page.
>
> Signed-off-by: Shannon Zhao
Please update the commit message, something like:
"Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
Kernel pages are 64K in size but
>>> On 25.01.16 at 06:26, wrote:
>
>> -Original Message-
>> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
>> Sent: Wednesday, January 20, 2016 9:31 PM
>> To: Jan Beulich ; Wu, Feng
>> Cc: Andrew Cooper ; George Dunlap
>> ; Tian, Kevin ; xen-
>> de...@lists.xen.org; Keir Fraser
On Mon, Jan 25, Ian Campbell wrote:
> Reported by: Olaf Hering
Tested-by: Olaf Hering
Thanks,
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Mon, 2016-01-25 at 06:54 -0700, Jan Beulich wrote:
> > > > On 25.01.16 at 13:16, wrote:
> > On Fri, 2016-01-22 at 08:42 -0700, Jan Beulich wrote:
> > > +#define MAP_MMIO_MAX_ITER 64 /* pretty arbitrary */
> > > +
> >
> > I suppose no existing in-tree code exceeds that (or there'd be more
> > p
>>> On 22.01.16 at 16:57, wrote:
>> On January 22, 2016 at 12:31am, wrote:
>> >>> On 21.01.16 at 17:16, wrote:
>> >> On January 20, 2016 at 7:29 pm, wrote:
>> >> >>> On 20.01.16 at 11:26, wrote:
>> >> >> On January 15, 2016 at 9:10, wrote:
>> >> >> >>> On 23.12.15 at 09:25, wrote:
>> >> >
>>> On 25.01.16 at 15:05, wrote:
> On Mon, 2016-01-25 at 06:54 -0700, Jan Beulich wrote:
>> > > > On 25.01.16 at 13:16, wrote:
>> > On Fri, 2016-01-22 at 08:42 -0700, Jan Beulich wrote:
>> > > +#define MAP_MMIO_MAX_ITER 64 /* pretty arbitrary */
>> > > +
>> >
>> > I suppose no existing in-tree c
On Mon, 2016-01-25 at 07:16 -0700, Jan Beulich wrote:
> > > > On 25.01.16 at 15:05, wrote:
> > On Mon, 2016-01-25 at 06:54 -0700, Jan Beulich wrote:
> > > > > > On 25.01.16 at 13:16, wrote:
> > > > On Fri, 2016-01-22 at 08:42 -0700, Jan Beulich wrote:
> > > > > +#define MAP_MMIO_MAX_ITER 64 /* pr
On Mon, 2016-01-25 at 13:27 +, Wei Liu wrote:
> On Mon, Jan 25, 2016 at 01:14:34PM +, Ian Campbell wrote:
> > "tools/libs/*: Use O_CLOEXEC on Linux and FreeBSD" left some dead code
> > in the FreeBSD case, which breaks the build on that platform.
> >
> > Also fix a typo "uint_32".
> >
> >
On Mon, 2016-01-25 at 13:25 +, Tim Deegan wrote:
> At 12:45 + on 25 Jan (1453725932), Ian Campbell wrote:
> > This:
> >
> > kdd-xen.c: In function 'kdd_access_physical_page':
> > kdd-xen.c:508:9: warning: implicit declaration of function
> > 'xc_map_foreign_range' [-Wimplicit-function-decl
On Mon, 2016-01-25 at 13:25 +, Tim Deegan wrote:
> At 13:18 + on 25 Jan (1453727891), Ian Campbell wrote:
> > We build most of tools using Werror and there seems to be know
> > deliberate reason for this to be an exception.
> >
> > Signed-off-by: Ian Campbell
>
> Acked-by: Tim Deegan
a
>>> On 23.01.16 at 08:38, wrote:
> Thinkpad x200 p8600 laptops have vt-d, vt-x and tpm. They also have intel
> integrated graphics 4 Series (gm45 chipset), supported through i915 driver.
>
> In December, a fix got introduced to Xen 4.6 through iommu=no-igfx switch.
> Before that fix, it was impos
>>> On 23.01.16 at 09:00, wrote:
> --- a/xen/include/xen/config.h
> +++ b/xen/include/xen/config.h
> @@ -7,7 +7,7 @@
> #ifndef __XEN_CONFIG_H__
> #define __XEN_CONFIG_H__
>
> -#include
> +#include
Why? I don't see why all source files need to include this new
header, no matter whether they
Ian Campbell writes ("Re: [Xen-devel] [PATCH XEN v8 02/29] tools: Refactor
/dev/xen/evtchn wrappers into libxenevtchn."):
> Various of the tools/libs/*/include/*.h have a
>
> /* Callers who don't care don't need to #include */
> typedef struct xentoollog_logger xentoollog_logger;
>
> bu
On Mon, Jan 25, Ian Campbell wrote:
> We build most of tools using Werror and there seems to be know
> deliberate reason for this to be an exception.
>
> Signed-off-by: Ian Campbell
This would have caught the kdd error.
Tested-by: Olaf Hering
Olaf
___
On 01/25/2016 09:35 AM, Ian Jackson wrote:
Ian Campbell writes ("Re: [Xen-devel] [PATCH XEN v8 02/29] tools: Refactor
/dev/xen/evtchn wrappers into libxenevtchn."):
Various of the tools/libs/*/include/*.h have a
/* Callers who don't care don't need to #include */
typedef struct xent
On Fri, Jan 15, 2016 at 11:28:45AM -0800, Paul E. McKenney wrote:
> On Fri, Jan 15, 2016 at 09:54:01AM -0800, Paul E. McKenney wrote:
> > On Fri, Jan 15, 2016 at 10:24:32AM +, Will Deacon wrote:
> > > See my earlier reply [1] (but also, your WRC Linux example looks more
> > > like a variant on
>>> On 23.01.16 at 18:25, wrote:
> Shannon Zhao writes:
>> --- a/xen/arch/x86/Kconfig
>> +++ b/xen/arch/x86/Kconfig
>> @@ -5,6 +5,7 @@ config X86
>> def_bool y
>> select COMPAT
>> select HAS_ACPI
>> +select ACPI_LEGACY_TABLES_LOOKUP if HAS_ACPI
>
> Since HAS_ACPI is selected ri
>>> On 23.01.16 at 09:00, wrote:
> v5: only factor the first Mb handling and the attribute of __vmap()
Much better.
> --- a/xen/drivers/acpi/osl.c
> +++ b/xen/drivers/acpi/osl.c
> @@ -92,11 +92,14 @@ acpi_os_map_memory(acpi_physical_address phys, acpi_size
> size)
> mfn_t mfn = _m
On Mon, 2016-01-25 at 14:35 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH XEN v8 02/29] tools:
> Refactor /dev/xen/evtchn wrappers into libxenevtchn."):
> > Various of the tools/libs/*/include/*.h have a
> >
> > /* Callers who don't care don't need to #include */
>
>>> On 23.01.16 at 10:19, wrote:
> From: Shannon Zhao
>
> When MADT is parsed, print GIC information to make the boot log look
> pretty.
>
> Signed-off-by: Hanjun Guo
> Signed-off-by: Tomasz Nowicki
> Signed-off-by: Shannon Zhao
Is this the equivalent of a Linux side commit? If so please na
On 25/01/16 14:47, Ian Campbell wrote:
> On Mon, 2016-01-25 at 14:35 +, Ian Jackson wrote:
>> Ian Campbell writes ("Re: [Xen-devel] [PATCH XEN v8 02/29] tools:
>> Refactor /dev/xen/evtchn wrappers into libxenevtchn."):
>>> Various of the tools/libs/*/include/*.h have a
>>>
>>> /* Callers wh
>>> On 23.01.16 at 10:20, wrote:
> --- a/xen/include/xen/acpi.h
> +++ b/xen/include/xen/acpi.h
> @@ -39,6 +39,10 @@
> #define ACPI_MADT_GET_POLARITY(inti) ACPI_MADT_GET_(POLARITY, inti)
> #define ACPI_MADT_GET_TRIGGER(inti) ACPI_MADT_GET_(TRIGGER, inti)
>
> +#define BAD_MADT_ENTRY(entry, end)
>>> On 23.01.16 at 10:20, wrote:
> From: Shannon Zhao
>
> This function could get the specified index entry of MADT table. This
> would be useful when it needs to get the contens of the entry.
>
> Cc: Jan Beulich
> Signed-off-by: Shannon Zhao
Again - if this is the counterpart to a Linux sid
>>> On 23.01.16 at 10:20, wrote:
> --- a/xen/include/xen/serial.h
> +++ b/xen/include/xen/serial.h
> @@ -170,7 +170,7 @@ struct ns16550_defaults {
> void ns16550_init(int index, struct ns16550_defaults *defaults);
> void ehci_dbgp_init(void);
>
> -void __init dt_uart_init(void);
> +void __init
On Sat, 23 Jan 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Sync the changes of HVM_PARAM_CALLBACK_VIA ABI introduced by
> Xen commit (public/hvm: export the HVM_PARAM_CALLBACK_VIA
> ABI in the API).
>
> Signed-off-by: Shannon Zhao
Acked-by: Stefano Stabellini
> include/xen/interfac
On Sat, 23 Jan 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Add a new delivery type:
> val[63:56] == 3: val[15:8] is flag: val[7:0] is a PPI.
> To the flag, bit 0 stands the interrupt mode is edge(1) or level(0) and
> bit 1 stands the interrupt polarity is active low(1) or high(0).
>
> Sig
On 01/22/2016 07:30 PM, Andrew Cooper wrote:
On 22/01/2016 23:32, Luis R. Rodriguez wrote:
On Fri, Jan 22, 2016 at 04:35:50PM -0500, Boris Ostrovsky wrote:
+ /*
+* See Documentation/x86/boot.txt.
+*
+* Version 2.12 supports Xen entry point but we will use default x
>>> On 23.01.16 at 10:20, wrote:
> --- a/xen/include/acpi/actbl2.h
> +++ b/xen/include/acpi/actbl2.h
> @@ -815,6 +815,15 @@ struct acpi_table_spcr {
>
> #define ACPI_SPCR_DO_NOT_DISABLE(1)
>
> +/* SPCR Interface type */
> +#define ACPI_SPCR_TYPE_16550 0
> +#define ACPI_SPCR_TYPE_1
On Mon, Jan 25, 2016 at 11:35:42AM +, David Vrabel wrote:
> On 25/01/16 11:29, Wei Liu wrote:
> >
> > That goes back to the old topic of how to make VirtIO work on Xen (PV in
> > particular). It's not easy task by any means.
>
> This is a (very) useful thing to solve anyway so why not go down
>
> > Or are you suggesting that perhaps the kernel should at boot time
> > print the build-id (like it does the changset)?
>
> Perhaps, albeit to me that's a bit orthogonal to being able to find out
> the build ID for a given binary.
I looked in the mkelf32 and it looks quite easy to make the
On Sat, 23 Jan 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> When booting with ACPI, it could get the event-channel irq through
> HVM_PARAM_CALLBACK_IRQ.
>
> Signed-off-by: Shannon Zhao
> ---
> arch/arm/xen/enlighten.c | 36 +++-
> 1 file changed, 35 insert
>>> On 19.01.16 at 08:30, wrote:
> Changes in v6:
> *2 patches merged are not included.
> *Don't write XSTATE_PKRU to PV's xcr0.
> *Use "if()" instead of "?:" in cpuid handling patch.
> *Update read_pkru function.
> *Use value 4 instead of CONFIG_PAGING_LEVELS.
> *Add George's patch for PFEC_insn_
On 01/25/2016 05:51 AM, David Vrabel wrote:
On 22/01/16 21:35, Boris Ostrovsky wrote:
This series introduces HVMlite support for unprivileged guests.
It has been tested on Intel/AMD, both 32- and 64-bit, including CPU on- and
offlining and save/restore. (Restore will result in APIC write warnin
From: Roger Pau Monne
Signed-off-by: Roger Pau Monné
Reported by: Konrad Rzeszutek Wilk
---
Cc: Ian Jackson
Cc: Ian Campbell
Cc: Wei Liu
---
tools/libxl/libxl_internal.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_
On Sat, 23 Jan 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Move xen_early_init() before efi_init(), then when calling efi_init()
> could initialize Xen specific UEFI.
>
> Check if it runs on Xen hypervisor through the flat dts.
>
> Signed-off-by: Shannon Zhao
Reviewed-by: Stefano Stabe
On Mon, 2016-01-25 at 14:49 +, Andrew Cooper wrote:
> On 25/01/16 14:47, Ian Campbell wrote:
> > On Mon, 2016-01-25 at 14:35 +, Ian Jackson wrote:
> > > Ian Campbell writes ("Re: [Xen-devel] [PATCH XEN v8 02/29] tools:
> > > Refactor /dev/xen/evtchn wrappers into libxenevtchn."):
> > > > Va
When splitting out various functionality from libxc into tools/libs/*
I attempted to make it possible to avoid callers being unnecessarily
exposed to the xentoollog interface by providing a typedef of the
xentoollog_logger handle in each of the headers.
However such typedefs are not allowed in C,
On 01/25/2016 05:53 AM, David Vrabel wrote:
On 22/01/16 21:35, Boris Ostrovsky wrote:
Xen's HVMlite guests will want to use them.
Please explain in detail why they are needed.
Actually, start_secondary is not needed anymore, I removed its use at
some point.
initial_pg_pmd (together with
On Sat, 23 Jan 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> When it's a Xen domain0 booting with ACPI, it will supply a /chosen and
> a /hypervisor node in DT. So check if it needs to enable ACPI.
>
> Signed-off-by: Shannon Zhao
Reviewed-by: Stefano Stabellini
> CC: Hanjun Guo
> ---
On 01/25/2016 06:04 AM, David Vrabel wrote:
On 22/01/16 21:35, Boris Ostrovsky wrote:
HVMlite guests (to be introduced in subsequent patches) share most
of the kernel initialization code with PV(H).
Where possible, HVMlite should share initialization with bare metal/HVM
and not PV(H).
This is
Ian Campbell writes ("[PATCH] tools: avoid redefinition of typedefs"):
> When splitting out various functionality from libxc into tools/libs/*
> I attempted to make it possible to avoid callers being unnecessarily
> exposed to the xentoollog interface by providing a typedef of the
> xentoollog_logg
>>> On 19.01.16 at 08:30, wrote:
> Signed-off-by: Huaitong Han
> ---
Please get used to put here per-patch info on what changed from the
previous revision.
> --- a/xen/arch/x86/mm/guest_walk.c
> +++ b/xen/arch/x86/mm/guest_walk.c
> @@ -90,6 +90,53 @@ static uint32_t set_ad_bits(void *guest_p, v
>>> On 19.01.16 at 08:30, wrote:
> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -579,6 +579,10 @@ int handle_xsetbv(u32 index, u64 new_bv)
> if ( (new_bv & ~xfeature_mask) || !valid_xcr0(new_bv) )
> return -EINVAL;
>
> +/* XCR0.PKRU is disabled on PV mode. */
On Sat, 23 Jan 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
> scan this to get the UEFI information.
>
> Signed-off-by: Shannon Zhao
> Acked-by: Rob Herring
> ---
> CC: Rob Herring
> ---
> Documentation/devicetree
>>> On 19.01.16 at 08:30, wrote:
> At the moment, the pfec argument to gva_to_gfn has two functions:
>
> * To inform guest_walk what kind of access is happenind
>
> * As a value to pass back into the guest in the event of a fault.
>
> Unfortunately this is not quite treated consistently: the hv
On Mon, Jan 25, 2016 at 03:50:52PM +, Stefano Stabellini wrote:
> On Sat, 23 Jan 2016, Shannon Zhao wrote:
> > From: Shannon Zhao
> >
> > Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
> > scan this to get the UEFI information.
> >
> > Signed-off-by: Shannon Zhao
>
>>> On 19.01.16 at 08:30, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4566,7 +4566,7 @@ void hvm_cpuid(unsigned int input, unsigned int *eax,
> unsigned int *ebx,
> __clear_bit(X86_FEATURE_APIC & 31, edx);
>
> /* Fix up OSXSAVE. */
> -
On Mon, 25 Jan 2016, Mark Rutland wrote:
> On Mon, Jan 25, 2016 at 03:50:52PM +, Stefano Stabellini wrote:
> > On Sat, 23 Jan 2016, Shannon Zhao wrote:
> > > From: Shannon Zhao
> > >
> > > Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
> > > scan this to get the UEFI
On 01/22/2016 06:32 PM, Luis R. Rodriguez wrote:
On Fri, Jan 22, 2016 at 04:35:50PM -0500, Boris Ostrovsky wrote:
+/*
+ * This routine (and those that it might call) should not use
+ * anything that lives in .bss since that segment will be cleared later
+ */
+void __init xen_prepare_hvmlite(voi
>>> On 25.01.16 at 16:16, wrote:
>>
>> > Or are you suggesting that perhaps the kernel should at boot time
>> > print the build-id (like it does the changset)?
>>
>> Perhaps, albeit to me that's a bit orthogonal to being able to find out
>> the build ID for a given binary.
>
>
> I looked in t
1 - 100 of 186 matches
Mail list logo