On 6/17/2016 11:25 AM, Corneliu ZUZU wrote:
On 6/16/2016 6:16 PM, Jan Beulich wrote:
On 16.06.16 at 16:12, wrote:
Prepare for ARM implementation of control-register write vm-events
by moving
X86-specific hvm_event_cr to the common-side.
Signed-off-by: Corneliu ZUZU
---
xen/arch/x86/hvm/ev
>>> On 21.06.16 at 08:19, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Thursday, March 17, 2016 3:51 PM
>>
>> As has been explained previously[1], SMAP (and with less relevance
>> also SMEP) is not compatible with 32-bit PV guests which aren't
>> aware/prepared to be run with t
>>> On 21.06.16 at 09:08, wrote:
> On 6/17/2016 11:25 AM, Corneliu ZUZU wrote:
>> On 6/16/2016 6:16 PM, Jan Beulich wrote:
>> On 16.06.16 at 16:12, wrote:
Prepare for ARM implementation of control-register write vm-events
by moving
X86-specific hvm_event_cr to the common-side.
flight 96009 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96009/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail REGR. vs. 95980
test-amd64-i386-xl-
On 6/20/2016 9:13 PM, George Dunlap wrote:
On 20/06/16 12:28, Yu Zhang wrote:
On 6/20/2016 6:55 PM, Jan Beulich wrote:
On 20.06.16 at 12:32, wrote:
On 20/06/16 11:25, Jan Beulich wrote:
On 20.06.16 at 12:10, wrote:
On 20/06/16 10:03, Yu Zhang wrote:
However, there are conflicts if we t
On 6/20/2016 9:38 PM, Jan Beulich wrote:
On 20.06.16 at 14:06, wrote:
Suppose resolve_misconfig() is modified to change all p2m_ioreq_server
entries(which also
have e.recalc flag turned on) back to p2m_ram_rw. And suppose we have
ioreq server 1, which
emulates gfn A, and ioreq server 2 which
>>> On 21.06.16 at 09:45, wrote:
> On 6/20/2016 9:38 PM, Jan Beulich wrote:
> On 20.06.16 at 14:06, wrote:
>>> However, if live migration is started(all pte entries invalidated
>>> again), resolve_misconfig() would
>>> change both gfn A's and gfn B's p2m type back to p2m_ram_rw, which means
>
flight 96015 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96015/
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
test-amd64-amd64-
hi,
i'm looking for a detailed tutorial on how to install Xen on a MinnowBoard
Max
Best Regards,
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> On 20.06.16 at 18:23, wrote:
> Here is printouts with applying the new logic
>
> [ 382.13] xen-pciback: :06:00.0: write request 4 bytes at 0xc = 4000
> [ 382.14] xen-pciback: :06:00.0: read 1 bytes at 0xc
> [ 382.28] xen-pciback: :06:00.0: read 1 bytes at 0xc = 0
>
With the Linux kernel commits
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Documentation/arm64/booting.txt?id=4370eec05a887b0cd4392cd5dc5b2713174745c0
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Documentation/arm64/booting.txt?id=a2c1d73b94ed49
In scif_uart_init() uart->baud is set to BAUD_AUTO. So its a basic error
if this is different later. Detect this by an ASSERT, but remove the
dead code normally never reached.
Signed-off-by: Dirk Behme
---
xen/drivers/char/scif-uart.c | 23 ++-
1 file changed, 6 insertions(+)
The two struct members baud and clock_hz are in the end read only
variables nowhere used for anything useful. Removing them makes
the code much simpler without changing any functionality.
Signed-off-by: Dirk Behme
---
xen/drivers/char/scif-uart.c| 13 +
xen/include/asm-arm/scif-u
Besides the 14MHz external clock, the SCIF might be clocked by an
internal 66MHz clock. Detect this clock based on the SCIF_DL register
being 0 (internal clock) or != 0 (external clock).
Signed-off-by: Dirk Behme
---
xen/drivers/char/scif-uart.c | 15 +--
1 file changed, 13 insertion
Hello Tamas,
On 02/06/16 23:52, Tamas K Lengyel wrote:
Mechanical renaming and relocation to the monitor subsystem.
Signed-off-by: Tamas K Lengyel
Acked-by: Razvan Cojocaru
Acked-by: Jan Beulich
For ARM bits:
Acked-by: Julien Grall
Regards,
--
Julien Grall
Hello Tamas,
On 02/06/16 23:52, Tamas K Lengyel wrote:
The monitor_get_capabilities check actually belongs to the monitor subsystem so
relocating and renaming it to sanitize the code's name and location. Mechanical
patch, no code changes introduced.
Signed-off-by: Tamas K Lengyel
Acked-by: And
>>> On 21.06.16 at 11:04, wrote:
On 20.06.16 at 18:23, wrote:
>> Here is printouts with applying the new logic
>>
>> [ 382.13] xen-pciback: :06:00.0: write request 4 bytes at 0xc =
> 4000
>> [ 382.14] xen-pciback: :06:00.0: read 1 bytes at 0xc
>> [ 382.28] xen-pcibac
On 6/21/2016 4:22 PM, Jan Beulich wrote:
On 21.06.16 at 09:45, wrote:
On 6/20/2016 9:38 PM, Jan Beulich wrote:
On 20.06.16 at 14:06, wrote:
However, if live migration is started(all pte entries invalidated
again), resolve_misconfig() would
change both gfn A's and gfn B's p2m type back to p
On Sat, Jun 18, 2016 at 01:12:36AM +0200, Dario Faggioli wrote:
> in both xenalyze and formats (for xentrace_format).
>
> In particular, in xenalyze, now that we have the precision
> of the fixed point load values in the tracepoint, show both
> the raw value and the (easier to interpreet) percenta
Hello Shanker,
On 19/06/16 00:45, Shanker Donthineni wrote:
The current driver doesn't support parsing Redistributor entries that
are described in the MADT GICC table. Not all the GIC implementors
places the Redistributor regions in the always-on power domain. On
systems, the UEFI firmware shoul
Hello Shanker,
On 19/06/16 00:45, Shanker Donthineni wrote:
Move the code that validates base address and does ioremap of GIC
distributor region to a separate function. Later patches need to
access the GICD region inside function gicv3_acpi_init() for
finding per CPU Redistributor size.
This p
>>> On 21.06.16 at 11:16, wrote:
>
> On 6/21/2016 4:22 PM, Jan Beulich wrote:
> On 21.06.16 at 09:45, wrote:
>>> On 6/20/2016 9:38 PM, Jan Beulich wrote:
>>> On 20.06.16 at 14:06, wrote:
> However, if live migration is started(all pte entries invalidated
> again), resolve_misco
flight 96026 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96026/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-build fail REGR. vs. 80927
build-i
On 6/21/2016 5:47 PM, Jan Beulich wrote:
On 6/21/2016 4:22 PM, Jan Beulich wrote:
Above modification would convert _all_ p2m_ioreq_server into
p2m_ram_rw, irrespective of log-dirty mode being active. Which
I don't think is what you want.
Well, this is another situation I found very interesti
On Mon, Jun 20, 2016 at 06:57:11AM -0600, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
>
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Mon, Jun 20, 2016 at 06:56:14AM -0600, Jan Beulich wrote:
> This allows elimination of the (ab)use of the high operation number
> bits for encoding continuations.
>
> Also limiting "nr" at the libxc level to 32 bits (the high 32 bits of
> the previous 64-bit parameter got ignore so far).
>
> S
On Mon, Jun 20, 2016 at 06:55:43AM -0600, Jan Beulich wrote:
> Also limiting "nr" at the libxc level to 32 bits (the high 32 bits of
> the previous 64-bit parameter got ignore so far).
>
> Signed-off-by: Jan Beulich
>
Reviewed-by: Wei Liu
___
Xen-de
On Mon, Jun 20, 2016 at 06:53:53AM -0600, Jan Beulich wrote:
> Note that this retains the hvmop interface definitions as those had
> (wrongly) been exposed to non-tool stack consumers (albeit the
> operation wouldn't have succeeded when requested by a domain for
> itself).
>
> Signed-off-by: Jan B
On Mon, Jun 20, 2016 at 06:56:41AM -0600, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Mon, Jun 20, 2016 at 06:53:23AM -0600, Jan Beulich wrote:
> Note that this adds validation of the "domain" interface structure
> field, which previously got ignored.
>
> Note further that this retains the hvmop interface definitions as those
> had (wrongly) been exposed to non-tool stack consum
On Mon, Jun 20, 2016 at 06:54:24AM -0600, Jan Beulich wrote:
> Note that this retains the hvmop interface definitions as those had
> (wrongly) been exposed to non-tool stack consumers (albeit the
> operation wouldn't have succeeded when requested by a domain for
> itself).
>
> Signed-off-by: Jan B
On Mon, Jun 20, 2016 at 06:54:57AM -0600, Jan Beulich wrote:
> Also limiting "nr" at the libxc level to 32 bits (the high 32 bits of
> the previous 64-bit parameter got ignore so far).
>
> Signed-off-by: Jan Beulich
>
Reviewed-by: Wei Liu
___
Xen-de
On Mon, Jun 20, 2016 at 06:57:47AM -0600, Jan Beulich wrote:
> Note that we can't adjust HVM_IOREQSRV_BUFIOREQ_* to properly obey
> name space rules, as these constants as in use by callers of the libxc
> interface.
>
> Signed-off-by: Jan Beulich
>
Reviewed-by: Wei Liu
___
On Mon, Jun 20, 2016 at 06:52:41AM -0600, Jan Beulich wrote:
> ... as a means to replace all HVMOP_* which a domain can't issue on
> itself (i.e. intended for use by only the control domain or device
> model).
>
> Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
Hello Shanker,
On 19/06/16 00:45, Shanker Donthineni wrote:
The redistributor address can be specified either as part of GICC or
GICR subtable depending on the power domain. The current driver
doesn't support parsing redistributor entry that is defined in GICC
subtable. The GIC CPU subtable entr
Some clocks might be used by Xen (drivers) and not by the Linux kernel. If
these are not registered by the Linux kernel, they might be disabled by the
Linux kernel's clk_disable_unused() as the kernel doesn't know that
they are used (by Xen drivers). The clock of the serial console handled by
Xen i
Hi, Dirk.
On Tue, Jun 21, 2016 at 12:15 PM, Dirk Behme wrote:
> In scif_uart_init() uart->baud is set to BAUD_AUTO. So its a basic error
> if this is different later. Detect this by an ASSERT, but remove the
> dead code normally never reached.
>
> Signed-off-by: Dirk Behme
> ---
> xen/drivers/c
Some clocks might be used by the Xen hypervisor and not by the Linux
kernel. If these are not registered by the Linux kernel, they might be
disabled by clk_disable_unused() as the kernel doesn't know that they
are used. The clock of the serial console handled by Xen is one
example for this. It migh
On Mon, Jun 20, 2016 at 06:03:42PM +0100, Ian Jackson wrote:
> We are in danger of getting stuck on this naming question. I would
> like everyone to put forward some suggestions for the name of thisr
> toplevel epo on xenbits.
>
> Hopefully we can find one that Andrew likes and that's acceptable
Hello Shanker,
On 19/06/16 00:45, Shanker Donthineni wrote:
Add a new function for parsing GICR subtable and move the code
that is specific to GICR table to new function without changing
the function gicv3_acpi_init() behavior.
Signed-off-by: Shanker Donthineni
---
xen/arch/arm/gic-v3.c | 64
On 21.06.2016 12:15, Dirk Behme wrote:
Some clocks might be used by Xen (drivers) and not by the Linux kernel. If
these are not registered by the Linux kernel, they might be disabled by the
Linux kernel's clk_disable_unused() as the kernel doesn't know that
they are used (by Xen drivers). The clo
On 21.06.2016 12:16, Dirk Behme wrote:
Some clocks might be used by the Xen hypervisor and not by the Linux
kernel. If these are not registered by the Linux kernel, they might be
disabled by clk_disable_unused() as the kernel doesn't know that they
are used. The clock of the serial console handle
Hello Shanker,
On 19/06/16 00:45, Shanker Donthineni wrote:
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 370cdeb..9492727 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -40,6 +40,12 @@ struct vtimer {
uint64_t cval;
}
Subject: Re: ARM Xen Bug #45: Is there a solution?
Date: Tue, 31 May 2016 11:44:23 +0100
From: Julien Grall
To: Dirk Behme , xen-devel@lists.xen.org
CC: Stefano Stabellini , Ian Jackson
Hello Dirk,
On 27/05/16 13:34, Dirk Behme wrote:
On 26.05.2016 11:00, Julien Grall wrote:
On 25/05/2016
On 20/06/16 18:03, Ian Jackson wrote:
> We are in danger of getting stuck on this naming question. I would
> like everyone to put forward some suggestions for the name of thisr
> toplevel epo on xenbits.
>
> Hopefully we can find one that Andrew likes and that's acceptable to
> the committers.
>
On 18/06/16 00:13, Dario Faggioli wrote:
> because it is cheaper, and there is no much point in
> randomizing which cpu gets selected anyway, as such
> choice will be overridden shortly after, in runq_tickle().
>
> If we really feel the need (e.g., we prove it worth with
> benchmarking), we can re
David Vrabel writes ("Re: [Xen-devel] xenbits "official" repo for XTF (was Re:
[PATCH 0/2] xtf: add launcher (+1 bugfix)"):
> It seems unfair to give Andrew's project a clunky (repo) name because
> osstest is not sufficiently discoverable.
>
> Perhaps you should consider renaming osstest to xen-c
Hello Shanker,
On 19/06/16 00:45, Shanker Donthineni wrote:
Split code that installs mmio handlers for GICD and Re-distributor
regions to a new function. The intension of this separation is to defer
steps that registers vgic_v2/v3 mmio handlers.
Looking at this patch and the follow-up ones, I
flight 96022 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96022/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs.
94856
test-amd64-i3
Hello Dirk,
On 21/06/16 10:08, Dirk Behme wrote:
With the Linux kernel commits
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Documentation/arm64/booting.txt?id=4370eec05a887b0cd4392cd5dc5b2713174745c0
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/comm
On 6/16/2016 7:11 PM, Tamas K Lengyel wrote:
On Thu, Jun 16, 2016 at 8:07 AM, Corneliu ZUZU wrote:
For VM_EVENT_FLAG_DENY to work, the vcpu must be paused (sync = 1) until the
vm-event is handled. A vm-event response having VM_EVENT_FLAG_DENY flag set
should also set the VM_EVENT_FLAG_VCPU_PAUS
Hi Julien,
On 21.06.2016 13:14, Julien Grall wrote:
Hello Dirk,
On 21/06/16 10:08, Dirk Behme wrote:
With the Linux kernel commits
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Documentation/arm64/booting.txt?id=4370eec05a887b0cd4392cd5dc5b2713174745c0
https://git.k
On 21/06/16 12:40, Dirk Behme wrote:
On 21.06.2016 13:14, Julien Grall wrote:
On 21/06/16 10:08, Dirk Behme wrote:
With the Linux kernel commits
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Documentation/arm64/booting.txt?id=4370eec05a887b0cd4392cd5dc5b2713174745c0
On 06/17/2016 08:32 AM, Jan Beulich wrote:
On 16.06.16 at 22:27, wrote:
>>> I.e. my plan was, once the backwards moves are small enough, to maybe
>>> indeed compensate them by maintaining a global variable tracking
>>> the most recently returned value. There are issues with such an
>>> appr
On 21/06/16 11:16, Oleksandr Tyshchenko wrote:
Hi, Dirk.
Hello Oleksandr,
On Tue, Jun 21, 2016 at 12:15 PM, Dirk Behme wrote:
In scif_uart_init() uart->baud is set to BAUD_AUTO. So its a basic error
if this is different later. Detect this by an ASSERT, but remove the
dead code normally ne
Hello Dirk,
On 21/06/16 10:15, Dirk Behme wrote:
The two struct members baud and clock_hz are in the end read only
variables nowhere used for anything useful. Removing them makes
the code much simpler without changing any functionality.
From my understanding, this patch is removing code you ju
Hello Dirk,
On 21/06/16 10:15, Dirk Behme wrote:
Besides the 14MHz external clock, the SCIF might be clocked by an
internal 66MHz clock. Detect this clock based on the SCIF_DL register
being 0 (internal clock) or != 0 (external clock).
Do you have a public link to the specification?
Signed-o
>>> On 21.06.16 at 14:05, wrote:
>
> On 06/17/2016 08:32 AM, Jan Beulich wrote:
> On 16.06.16 at 22:27, wrote:
I.e. my plan was, once the backwards moves are small enough, to maybe
indeed compensate them by maintaining a global variable tracking
the most recently returned val
Hi Julien,
On 21.06.2016 14:20, Julien Grall wrote:
Hello Dirk,
On 21/06/16 10:15, Dirk Behme wrote:
Besides the 14MHz external clock, the SCIF might be clocked by an
internal 66MHz clock. Detect this clock based on the SCIF_DL register
being 0 (internal clock) or != 0 (external clock).
Do y
On 21/06/16 13:30, Dirk Behme wrote:
diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c
index bc157fe..678f46b 100644
--- a/xen/drivers/char/scif-uart.c
+++ b/xen/drivers/char/scif-uart.c
@@ -107,8 +107,19 @@ static void __init scif_uart_init_preirq(struct
serial_port *port)
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 20 June 2016 13:58
> To: xen-devel
> Cc: Andrew Cooper; Paul Durrant; Wei Liu; George Dunlap; Ian Jackson;
> Stefano Stabellini; dgde...@tycho.nsa.gov; Tim (Xen.org)
> Subject: [PATCH 10/11] hvmctl: convert HVMOP_*i
On Tue, Jun 21, 2016 at 3:15 PM, Julien Grall wrote:
>
>
> On 21/06/16 11:16, Oleksandr Tyshchenko wrote:
>>
>> Hi, Dirk.
>
>
> Hello Oleksandr,
Hello Julien.
>
>
>> On Tue, Jun 21, 2016 at 12:15 PM, Dirk Behme
>> wrote:
>>>
>>> In scif_uart_init() uart->baud is set to BAUD_AUTO. So its a basic
Hello Oleksandr,
On 21.06.2016 14:54, Oleksandr Tyshchenko wrote:
On Tue, Jun 21, 2016 at 3:15 PM, Julien Grall wrote:
On 21/06/16 11:16, Oleksandr Tyshchenko wrote:
Hi, Dirk.
Hello Oleksandr,
Hello Julien.
On Tue, Jun 21, 2016 at 12:15 PM, Dirk Behme
wrote:
In scif_uart_init()
On 21/06/16 13:54, Oleksandr Tyshchenko wrote:
On Tue, Jun 21, 2016 at 3:15 PM, Julien Grall wrote:
On Tue, Jun 21, 2016 at 12:15 PM, Dirk Behme
wrote:
I have some doubt that the current code is valid. The clock frequency is
hardcoded (see SCIF_CLK_FREQ), so are you saying that the frequenc
On Tue, Jun 21, 2016 at 4:07 PM, Julien Grall wrote:
>
>
> On 21/06/16 13:54, Oleksandr Tyshchenko wrote:
>>
>> On Tue, Jun 21, 2016 at 3:15 PM, Julien Grall
>> wrote:
On Tue, Jun 21, 2016 at 12:15 PM, Dirk Behme
wrote:
>>>
>>> I have some doubt that the current code is valid. The
The x86 version of the function xenmem_add_to_physmap_one contains
variable name gpfn and gfn which make the code very confusing.
I have left unchanged for now.
Also, rename gpfn to gfn in the ARM version as the latter is the correct
acronym for a guest physical frame.
Finally, remove the trailin
to avoid mixing machine frame with guest frame.
Signed-off-by: Julien Grall
Acked-by: Jan Beulich
---
Cc: Stefano Stabellini
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Konrad Rzeszutek Wilk
Cc: Tim Deegan
Cc: Wei Liu
Changes in v3:
- Use mfn_add
Hello all,
Some of the ARM functions are mixing gfn vs mfn and even physical vs frame.
To avoid more confusion, this patch series makes use of the terminology
described in xen/include/xen/mm.h and the associated typesafe.
I pushed a branch with this series applied on xenbits:
git://xenbits.xen.o
The prototype and the declaration of p2m_lookup disagree on how the
function should be used. One expect a frame number whilst the other
an address.
Thankfully, everyone is using with an address today. However, most of
the callers have to convert a guest frame to an address. Modify
the interface to
p2m_cache_flush is expecting GFNs in parameter and not MFNs. Rename
the variable to *gfn* and use typesafe to avoid possible misusage.
Note that the type of the parameters 'start' and 'end' is changed
from xen_pfn_t (aka uint64_t) to gfn_t (aka unsigned long). This
means that a truncation will occ
Also rename some variables to gfn or mfn when it does not require much
rework.
Finally replace %hu with %d when printing the domain id in
guest_physmap_add_entry (arch/x86/mm/p2m.c).
Signed-off-by: Julien Grall
Acked-by: Jan Beulich
---
Cc: Stefano Stabellini
Cc: Jan Beulich
Cc: Andrew Coope
Those helpers will be useful to do common operations without having to
unbox/box manually the GFNs/MFNs.
Signed-off-by: Julien Grall
---
Cc: Stefano Stabellini
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Konrad Rzeszutek Wilk
Cc: Tim Deegan
Cc: Wei Liu
Ch
The correct acronym for a guest physical frame is gfn. Also use
the recently introduced typesafe gfn/mfn to avoid mixing the two
different kind of frame.
Signed-off-by: Julien Grall
Acked-by: Jan Beulich
---
Cc: Stefano Stabellini
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian
The correct acronym for a guest physical frame is gfn. Also use
the typesafe gfn to ensure that a guest frame is effectively used.
Signed-off-by: Julien Grall
---
Changes in v2:
- Remove extra pair of brackets.
---
xen/arch/arm/domain.c | 4 ++--
xen/arch/arm/mm.c
On Tue, Jun 21, 2016 at 4:01 PM, Dirk Behme wrote:
> Hello Oleksandr,
>
>
> On 21.06.2016 14:54, Oleksandr Tyshchenko wrote:
>>
>> On Tue, Jun 21, 2016 at 3:15 PM, Julien Grall
>> wrote:
>>>
>>>
>>>
>>> On 21/06/16 11:16, Oleksandr Tyshchenko wrote:
Hi, Dirk.
>>>
>>>
>>>
>>> Hello
>>> On 17.06.16 at 05:37, wrote:
> @@ -546,17 +550,37 @@ static int __must_check iommu_flush_all(void)
> struct acpi_drhd_unit *drhd;
> struct iommu *iommu;
> int flush_dev_iotlb;
> +int rc = 0;
>
> flush_all_cache();
> for_each_drhd_unit ( drhd )
> {
> +
flight 96038 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96038/
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 96055 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96055/
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 06/21/2016 04:28 AM, Julien Grall wrote:
Hello Shanker,
On 19/06/16 00:45, Shanker Donthineni wrote:
The current driver doesn't support parsing Redistributor entries that
are described in the MADT GICC table. Not all the GIC implementors
places the Redistributor regions in the always-on po
On 21/06/16 14:37, Shanker Donthineni wrote:
On 06/21/2016 04:28 AM, Julien Grall wrote:
On 19/06/16 00:45, Shanker Donthineni wrote:
The current driver doesn't support parsing Redistributor entries that
are described in the MADT GICC table. Not all the GIC implementors
places the Redistribut
On 06/21/2016 05:16 AM, Julien Grall wrote:
Hello Shanker,
On 19/06/16 00:45, Shanker Donthineni wrote:
The redistributor address can be specified either as part of GICC or
GICR subtable depending on the power domain. The current driver
doesn't support parsing redistributor entry that is defi
On 06/21/2016 01:28 PM, Jan Beulich wrote:
On 21.06.16 at 14:05, wrote:
>
>>
>> On 06/17/2016 08:32 AM, Jan Beulich wrote:
>> On 16.06.16 at 22:27, wrote:
> I.e. my plan was, once the backwards moves are small enough, to maybe
> indeed compensate them by maintaining a global v
On 06/21/2016 05:17 AM, Julien Grall wrote:
Hello Shanker,
On 19/06/16 00:45, Shanker Donthineni wrote:
Add a new function for parsing GICR subtable and move the code
that is specific to GICR table to new function without changing
the function gicv3_acpi_init() behavior.
Signed-off-by: Shank
On 06/21/2016 08:50 AM, Julien Grall wrote:
On 21/06/16 14:37, Shanker Donthineni wrote:
On 06/21/2016 04:28 AM, Julien Grall wrote:
On 19/06/16 00:45, Shanker Donthineni wrote:
The current driver doesn't support parsing Redistributor entries that
are described in the MADT GICC table. Not
This will match how PMU errors are reported at check_hw_exists()'s
msr_fail label, which is reached when VPMU initialzation fails.
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/pmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/xen/pmu.c b/arch/x86/xen/pmu.c
ind
On Tue, Jun 21, 2016 at 10:17:33AM -0400, Boris Ostrovsky wrote:
> This will match how PMU errors are reported at check_hw_exists()'s
> msr_fail label, which is reached when VPMU initialzation fails.
>
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> arch/x86/xen/pmu
Signed-off-by: Juergen Gross
---
tools/libxl/libxl_create.c | 72 ++
1 file changed, 35 insertions(+), 37 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index c4e85f0..e93b880 100644
--- a/tools/libxl/libxl_create.c
+
Signed-off-by: Juergen Gross
---
tools/libxl/libxl_create.c | 54 ++--
tools/libxl/libxl_internal.h | 1 +
tools/libxl/libxl_pci.c | 36 +
3 files changed, 44 insertions(+), 47 deletions(-)
diff --git a/tools/libxl/libxl
Instead of duplicate coding for each device type (vtpms, usbctrls, ...)
especially on domain creation introduce a framework for that purpose.
Signed-off-by: Juergen Gross
---
tools/libxl/libxl.c | 12
tools/libxl/libxl_create.c | 163 +--
Instead of duplicate coding for each device type (vtpms, usbctrls, ...)
especially on domain creation introduce a framework for that purpose.
I especially found it annoying that e.g. the vtpm callback issued the
error message for a failed attach of nic devices.
Juergen Gross (3):
libxl: add fra
On 21/06/16 16:17, Boris Ostrovsky wrote:
> This will match how PMU errors are reported at check_hw_exists()'s
> msr_fail label, which is reached when VPMU initialzation fails.
>
> Signed-off-by: Boris Ostrovsky
Acked-by: Juergen Gross
> ---
> arch/x86/xen/pmu.c | 2 +-
> 1 file changed, 1 in
On 06/21/2016 05:49 AM, Julien Grall wrote:
Hello Shanker,
On 19/06/16 00:45, Shanker Donthineni wrote:
Split code that installs mmio handlers for GICD and Re-distributor
regions to a new function. The intension of this separation is to defer
steps that registers vgic_v2/v3 mmio handlers.
L
Current overlap check is evaluating to false a case where a filter field
is fully contained (proper subset) of a r/w request.
This change applies classical overlap check instead to include
all the scenarios.
Related to https://www.mail-archive.com/xen-devel@lists.xen.org/msg72174.html
Cc: Jan Beu
On 21/06/16 10:47, Jan Beulich wrote:
> And then - didn't we mean to disable that part of XenGT during
> migration, i.e. temporarily accept the higher performance
> overhead without the p2m_ioreq_server entries? In which case
> flipping everything back to p2m_ram_rw after (completed
On 21/06/16 15:16, Shanker Donthineni wrote:
On 06/21/2016 08:50 AM, Julien Grall wrote:
On 21/06/16 14:37, Shanker Donthineni wrote:
On 06/21/2016 04:28 AM, Julien Grall wrote:
On 19/06/16 00:45, Shanker Donthineni wrote:
The current driver doesn't support parsing Redistributor entries tha
Here is what we have gathered so far:
1. Virtlogd is not the right answer to XSA-180 because it is inherently
designed to work within libvirt.
2. Syslog is not suitable because it doesn't provide a fd for QEMU to
write to.
3. Logrotate is not suitable because it only rotates periodically.
4.
On 21/06/16 15:36, Shanker Donthineni wrote:
On 06/21/2016 05:49 AM, Julien Grall wrote:
Hello Shanker,
On 19/06/16 00:45, Shanker Donthineni wrote:
Split code that installs mmio handlers for GICD and Re-distributor
regions to a new function. The intension of this separation is to defer
st
On 20/05/16 08:26, Juergen Gross wrote:
> The pv_time_ops structure contains a function pointer for the
> "steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86
> uses its own mechanism to account for the "stolen" time a thread wasn't
> able to run due to hypervisor scheduling.
>
On Tue, Jun 21, 2016 at 5:23 AM, Jan Beulich wrote:
> >>> On 21.06.16 at 11:04, wrote:
> On 20.06.16 at 18:23, wrote:
> >> Here is printouts with applying the new logic
> >>
> >> [ 382.13] xen-pciback: :06:00.0: write request 4 bytes at 0xc =
> > 4000
> >> [ 382.14] xen-pciba
flight 96031 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96031/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 95849
test-amd64-amd64-xl-qemuu-
1 - 100 of 159 matches
Mail list logo
