On 03/15/2016 08:18 PM, Konrad Rzeszutek Wilk wrote:
On Mon, Mar 14, 2016 at 05:55:37PM +, Anthony PERARD wrote:
@@ -624,8 +628,6 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
if ( !dom->device_model )
{
-size_t start_info_size = sizeof(struct hvm_
Now that Xen no longer allocates irqs in _cpu_up() we can restore
commit a89941816726 ("hotplug: Prevent alloc/free of irq descriptors
during cpu up/down")
Signed-off-by: Boris Ostrovsky
---
arch/x86/kernel/smpboot.c | 11 ---
kernel/cpu.c |8
2 fil
On 03/17/2016 12:03 PM, David Vrabel wrote:
On 17/03/16 12:45, Boris Ostrovsky wrote:
Moving an unmasked irq may result in irq handler being invoked on both
source and target CPUs.
With 2-level this can happen as follows:
On source CPU:
evtchn_2l_handle_events
On 03/15/2016 12:57 PM, Olaf Hering wrote:
On Tue, Mar 01, Boris Ostrovsky wrote:
on domU:
[root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]# od -N 1 -j 4096 /dev/mem
od: /dev/mem: read error: Bad address
001
[root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]#
with
(XEN) mm.c:1767
On 03/21/2016 05:29 PM, Boris Ostrovsky wrote:
On 03/15/2016 12:57 PM, Olaf Hering wrote:
On Tue, Mar 01, Boris Ostrovsky wrote:
on domU:
[root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]# od -N 1 -j 4096
/dev/mem
od: /dev/mem: read error: Bad address
001
[root@dhcp-burlington7-2nd-B
On 03/22/2016 04:46 PM, Firas Azar wrote:
Andrew:
Currently if we use pygrub --isconfig , there is a good chance
that this command could fail with an "out of memory" error. This can
happen especially if the image file in question is at least a few
gigabytes in size and the dom0_mem setting is
On 03/23/2016 07:33 AM, Juergen Gross wrote:
On 23/03/16 11:55, Andrew Cooper wrote:
On 23/03/16 10:52, Juergen Gross wrote:
On 23/03/16 11:32, David Vrabel wrote:
On 23/03/16 10:25, Jan Beulich wrote:
On 23.03.16 at 11:14, wrote:
7. Report type according to features found (this is a little
On 03/17/2016 01:51 PM, Jonathan Davies wrote:
Encapsulate the request in a record that is passed from do_input to
process_packet and input_handle_error.
This will be helpful when keeping track of the requests made as part of a
transaction.
Signed-off-by: Jonathan Davies
Reviewed-by: Andrew Co
On 03/24/2016 06:49 PM, Andrew Cooper wrote:
On 24/03/2016 22:22, Boris Ostrovsky wrote:
On 03/17/2016 01:51 PM, Jonathan Davies wrote:
Encapsulate the request in a record that is passed from do_input to
process_packet and input_handle_error.
This will be helpful when keeping track of the
On 03/24/2016 10:53 PM, Steven Haigh wrote:
Hi all,
Firstly, I've cross-posted this to xen-devel and the lkml - as this
problem seems to only exist when using kernel 4.4 as a Xen DomU kernel.
I have also CC'ed Greg KH for his awesome insight as maintainer.
Please CC myself into replies - as I'm
On 03/25/2016 10:05 AM, Steven Haigh wrote:
On 25/03/2016 11:23 PM, Boris Ostrovsky wrote:
On 03/24/2016 10:53 PM, Steven Haigh wrote:
Hi all,
Firstly, I've cross-posted this to xen-devel and the lkml - as this
problem seems to only exist when using kernel 4.4 as a Xen DomU kernel.
I
On 03/25/2016 10:53 AM, Konrad Rzeszutek Wilk wrote:
On Thu, Mar 17, 2016 at 09:03:25AM -0400, Boris Ostrovsky wrote:
This call has always been missing from xen_play dead() but until
recently this was rather benign. With new cpu hotplug framework
however this call is required, otherwise a hot
On 03/25/2016 11:10 AM, Konrad Rzeszutek Wilk wrote:
On Thu, Mar 17, 2016 at 09:33:32AM -0400, Boris Ostrovsky wrote:
Commit ce0d3c0a6fb1 ("genirq: Revert sparse irq locking around
__cpu_up() and move it to x86 for now") reverted irq locking
introduced by commit a89941816726
On 03/25/2016 12:04 PM, Steven Haigh wrote:
It may not actually be the full logs. Once the system gets really upset,
you can't run anything - as such, grabbing anything from dmesg is not
possible.
The logs provided above is all that gets spat out to the syslog server.
I'll try tinkering with a
On 03/28/2016 05:34 AM, Fanny Dwargee wrote:
Hi,
I'm currently using Xen v4.6.1 compiled from sources on Linux Debian
Jessie and I would like to change the CPUID hypervisor vendor string
when queried from a HVM DomU (Windows7 SP1 64 bits).
According to http://www.sandpile.org/x86/cpuid.htm#l
On 03/29/2016 05:08 AM, Jonathan Davies wrote:
On Thu, Mar 24, 2016 at 07:57:30PM -0400, Boris Ostrovsky wrote:
On 03/24/2016 06:49 PM, Andrew Cooper wrote:
On 24/03/2016 22:22, Boris Ostrovsky wrote:
On 03/17/2016 01:51 PM, Jonathan Davies wrote:
Encapsulate the request in a record that is
On 03/29/2016 04:56 AM, Steven Haigh wrote:
Interestingly enough, this just happened again - but on a different
virtual machine. I'm starting to wonder if this may have something to do
with the uptime of the machine - as the system that this seems to happen
to is always different.
Destroying it
On 03/29/2016 10:19 AM, Toshi Kani wrote:
On Tue, 2016-03-29 at 12:34 +0200, Ingo Molnar wrote:
I'd appreciate if someone can test this patch-set on Xen to verify that
there is no change in "x86/PAT: Configuration [0-7] .." message in
dmesg.
So I don't have a Xen setup, but hopefully such test
On 03/29/2016 02:04 PM, Steven Haigh wrote:
Greg, please see below - this is probably more for you...
On 03/29/2016 04:56 AM, Steven Haigh wrote:
Interestingly enough, this just happened again - but on a different
virtual machine. I'm starting to wonder if this may have something to do
with the
: Boris Ostrovsky
This should be Tested-by (and maybe Reported-by). Reviewed-by implies
that I understood what you did. I make no such claim ;-)
-boris
---
tools/ocaml/xenstored/process.ml |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/ocaml/xenstored
On 04/01/2016 03:54 AM, Paul Durrant wrote:
The code in hvm/hvm.c related to handling I/O emulation using the ioreq
server framework is large and mostly self-contained.
This patch separates the ioreq server code into a new hvm/ioreq.c source
module and accompanying asm-x86/hvm/ioreq.h header fil
On 04/04/2016 12:30 PM, David Vrabel wrote:
On 04/04/16 17:21, Julien Grall wrote:
(CC Stefano new e-mail address)
Hello Anna-Maria,
On 04/04/2016 13:32, Anna-Maria Gleixner wrote:
Xen guests do not offline/online CPUs during suspend/resume and
therefore FROZEN notifier transitions are not re
ioreq server list needs to be initialized for PVH guests. This list is
walked in handle_hvm_io_completion() by all guests in HVM containers and
leaving it uninitialized may cause PVH guests to crash there.
Signed-off-by: Boris Ostrovsky
---
xen/arch/x86/hvm/hvm.c | 4 ++--
xen/arch/x86/hvm
return value to zero when native_rdmsr_safe fails
With Xen (on top of eb1af3b):
Tested-by: Boris Ostrovsky
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Signed-off-by: Boris Ostrovsky
---
tools/firmware/hvmloader/acpi/acpi2_0.h | 1 +
tools/firmware/hvmloader/acpi/build.c | 68 ++---
tools/firmware/hvmloader/util.c | 2 +-
3 files changed, 39 insertions(+), 32 deletions(-)
diff --git a/tools/firmware
Users other than hvmloader may provide TIS address as virtual.
Signed-off-by: Boris Ostrovsky
---
tools/firmware/hvmloader/acpi/acpi2_0.h | 4 ++
tools/firmware/hvmloader/acpi/build.c | 65 +
tools/firmware/hvmloader/util.c | 4 ++
3 files changed, 41
acpi_info can be initialized by hvmloader itself. Now ACPI code
doesn't need to use hvmloader-private variables/routines such as
uart_exists(), lpt_exists() etc.
Signed-off-by: Boris Ostrovsky
---
tools/firmware/hvmloader/acpi/acpi2_0.h | 18 ++
tools/firmware/hvmloader/acpi/bu
Some users of ACPI builder may be building tables in virtual address space.
Signed-off-by: Boris Ostrovsky
---
tools/firmware/hvmloader/acpi/acpi2_0.h | 4
tools/firmware/hvmloader/acpi/build.c | 3 +--
tools/firmware/hvmloader/config.h | 3 +--
tools/firmware/hvmloader/util.c
Signed-off-by: Boris Ostrovsky
---
xen/arch/x86/hvm/vlapic.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 01a8430..d8b887c 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -1133,6 +1133,9 @@ void
In preparation for moving out ACPI builder make all
BIOSes call hvmloader_acpi_build_tables() instead of
calling ACPI code directly.
Signed-off-by: Boris Ostrovsky
---
tools/firmware/hvmloader/ovmf.c| 2 +-
tools/firmware/hvmloader/rombios.c | 2 +-
tools/firmware/hvmloader/seabios.c | 2
With that, xenstore_read() won't need to be done in ACPI code
Signed-off-by: Boris Ostrovsky
---
tools/firmware/hvmloader/acpi/acpi2_0.h | 6 ++
tools/firmware/hvmloader/acpi/build.c | 20 +++-
tools/firmware/hvmloader/util.c | 12
3 files change
Signed-off-by: Boris Ostrovsky
---
tools/firmware/hvmloader/acpi/acpi2_0.h | 1 +
tools/firmware/hvmloader/acpi/build.c | 9 ++---
tools/firmware/hvmloader/util.c | 3 ++-
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h
b
ACPI sources will be available to various component which will build
them according to their own rules. ACPI directory will only build
sources.
Signed-off-by: Boris Ostrovsky
---
tools/firmware/hvmloader/Makefile | 17 ++---
tools/firmware/hvmloader/acpi/Makefile
Initiale it in hvmloader, avoiding ACPI code's use of xenstore_read()
Signed-off-by: Boris Ostrovsky
---
tools/firmware/hvmloader/acpi/acpi2_0.h | 4
tools/firmware/hvmloader/acpi/build.c | 22 +++---
tools/firmware/hvmloader/util.c | 10 ++
3
BSD). No passthrough testing has been done.
(I realize that many people are busy because of Friday's freeze but I figured
I'd
post it now in the hope that this may get some reading so that we can talk about
it at the hackathon)
Boris Ostrovsky (20):
hvmloader: Provide hvmloa
No need for ACPI code to rely on hvm_info.
Signed-off-by: Boris Ostrovsky
---
tools/firmware/hvmloader/acpi/acpi2_0.h | 13 +
tools/firmware/hvmloader/acpi/build.c | 49 +
tools/firmware/hvmloader/util.c | 11
3 files changed, 49
Non-hvmloader users may be building tables in virtual address space
and therefore we need to make sure that values that end up in tables
are physical addresses.
Signed-off-by: Boris Ostrovsky
---
tools/firmware/hvmloader/acpi/build.c | 47 ++-
1 file changed, 24
This way ACPI code won't use xenstore-read() and hvm_param_set()
which are private to hvmloader.
Signed-off-by: Boris Ostrovsky
---
tools/firmware/hvmloader/acpi/acpi2_0.h | 1 +
tools/firmware/hvmloader/acpi/build.c | 30 +++---
tools/firmware/hvmloader/u
Signed-off-by: Boris Ostrovsky
---
xen/common/Makefile | 2 +-
xen/common/libacpi/Makefile | 15 ---
xen/common/libacpi/acpi2_0.h | 6 ++
xen/common/libacpi/build.c | 15 +++
xen/common/libacpi/mk_dsdt.c | 4
5 files changed, 38 insertions(+), 4
;t have to re-define them themselves.
Explicitly define a few things that are currently available to to build.c
via util.h.
Remove unnecessary #include "../config.h" from static_tables.c
Signed-off-by: Boris Ostrovsky
---
tools/firmware/hvmloader/Makefile | 2 +-
tool
PVH guests may request LAPIC emulation (and nothing else)
Signed-off-by: Boris Ostrovsky
---
xen/arch/x86/domain.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index a6d721b..3b614d7 100644
--- a
Components that wish to use ACPI builder will need to provide their own
mem_alloc() and virt_to_phys() routines. Pointers to these routines will
be passed to the builder as memory ops.
Signed-off-by: Boris Ostrovsky
---
tools/firmware/hvmloader/acpi/acpi2_0.h | 6 ++
tools/firmware/hvmloader
Signed-off-by: Boris Ostrovsky
---
tools/libxc/Makefile | 22 +++-
tools/libxc/include/xc_dom.h | 1 +
tools/libxc/xc_acpi.c | 268 ++
tools/libxc/xc_dom_x86.c | 7 +
tools/libxl/libxl_x86.c | 19 +--
xen
Signed-off-by: Boris Ostrovsky
---
.gitignore| 8
tools/firmware/hvmloader/Makefile | 3 +--
tools/firmware/hvmloader/smbios.c | 1 +
tools/firmware/rombios/32bit
With this flags set guests will not try to set up SCI.
Signed-off-by: Boris Ostrovsky
---
xen/common/libacpi/build.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/common/libacpi/build.c b/xen/common/libacpi/build.c
index e53b4a7..7f2662a 100644
--- a/xen/common/libacpi/build.c
+++ b
On 04/06/2016 08:06 PM, Luis R. Rodriguez wrote:
We have 4 types of x86 platforms that disable RTC:
* Intel MID
* Lguest - uses paravirt
* Xen dom-U - uses paravirt
* x86 on legacy systems annotated with an ACPI legacy flag
We can consolidate all of these into a platform specific le
On 04/06/2016 08:06 PM, Luis R. Rodriguez wrote:
There is already a check for apm_info.bios == 0, the
apm_info.bios is set from the boot_params.apm_bios_info.
Both Xen and lguest, which are also the only ones that set
paravirt_enabled to true, never set the apm_bios.info. The
Xen folks are sure
On 04/08/2016 02:29 AM, Luis R. Rodriguez wrote:
On Thu, Apr 7, 2016 at 10:18 PM, Juergen Gross wrote:
On 08/04/16 02:32, Luis R. Rodriguez wrote:
On Thu, Apr 07, 2016 at 08:55:54AM -0400, Boris Ostrovsky wrote:
On 04/06/2016 08:06 PM, Luis R. Rodriguez wrote:
We have 4 types of x86
On 04/08/2016 03:59 AM, Juergen Gross wrote:
On 08/04/16 09:36, Luis R. Rodriguez wrote:
On Fri, Apr 8, 2016 at 12:13 AM, Juergen Gross wrote:
On 08/04/16 08:56, Luis R. Rodriguez wrote:
On Thu, Apr 7, 2016 at 11:38 PM, Juergen Gross wrote:
Okay. Another idea (not sure whether this is reall
On 04/08/2016 07:40 PM, Luis R. Rodriguez wrote:
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index 1ae89a2721d6..8bb8c1a4615a 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -142,6 +142,15 @@ struct x86_cpuinit_ops {
struct
f 1, to prevent them from faulting when
accessing IO ports. This bug manifests as a crash after migrate, as the vIOPL
reverts back to the default of 0, and the guest suffers an unexpected #GP
fault.
Signed-off-by: Andrew Cooper
Tested-by: Boris Ostrovsky
(save/restore was part of brokenness as
t is not initialized. */
+ if (irq == -1)
+ return;
+
xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
}
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Ping?
On 03/17/2016 09:33 AM, Boris Ostrovsky wrote:
Original version of that patch (commit a89941816726) had to be reverted
due to Xen allocating irqs in its cpu_up ops.
The first patch moves allocations into hotplug notifiers and the second
one restores the original patch (with minor
On 04/24/2016 04:23 PM, Borislav Petkov wrote:
On Mon, Feb 01, 2016 at 10:38:48AM -0500, Boris Ostrovsky wrote:
Start HVMlite guest at XEN_ELFNOTE_PHYS32_ENTRY address. Setup hypercall
page, initialize boot_params, enable early page tables.
Since this stub is executed before kernel entry point
On 04/25/2016 09:47 AM, Borislav Petkov wrote:
On Mon, Apr 25, 2016 at 09:21:27AM -0400, Boris Ostrovsky wrote:
I was following Documentation/x86/boot.txt (plus comments in code preceding
those two routines) which I considered to be the API.
We are supposed to come to startup_32 with paging
On 04/25/2016 10:11 AM, Borislav Petkov wrote:
On Mon, Apr 25, 2016 at 09:54:37AM -0400, Boris Ostrovsky wrote:
Yes, those.
I don't think the ones in arch/x86/kernel/head_{32,64}.S are ABI.
Hmm... I thought that everything specified in boot.txt was ABI.
I don't think we c
On 04/25/2016 11:22 AM, Borislav Petkov wrote:
On Mon, Apr 25, 2016 at 10:42:15AM -0400, Boris Ostrovsky wrote:
Hmm... I thought that everything specified in boot.txt was ABI.
But those are not there.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/x86
On 04/27/2016 05:35 AM, David Vrabel wrote:
On 27/04/16 06:02, Juergen Gross wrote:
On 21/04/16 11:30, Stefano Stabellini wrote:
On Thu, 21 Apr 2016, Juergen Gross wrote:
On 20/04/16 15:15, Stefano Stabellini wrote:
b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
of l
On 04/27/2016 09:40 AM, David Vrabel wrote:
On 27/04/16 14:38, Boris Ostrovsky wrote:
int xen_nr_legacy_irqs()
{
if (xen_hvm_domain())
return nr_legacy_irqs();
if (xen_initial_domain())
return NR_IRQS_LEGACY;
return 0;
}
Yeah, if that does the right thing
On 05/09/2016 12:40 PM, Kevin Moraga wrote:
>
> On 05/09/2016 09:53 AM, Jan Beulich wrote:
> On 09.05.16 at 16:52, wrote:
>>> On 05/09/2016 04:08 AM, Jan Beulich wrote:
>>> On 09.05.16 at 00:51, wrote:
> I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0
> and
On 05/09/2016 01:22 PM, Kevin Moraga wrote:
>
> On 05/09/2016 11:15 AM, Boris Ostrovsky wrote:
>> On 05/09/2016 12:40 PM, Kevin Moraga wrote:
>>> On 05/09/2016 09:53 AM, Jan Beulich wrote:
>>>>>>> On 09.05.16 at 16:52, wrote:
>>>>> On 05/0
emul path, even if
> it did not originate from an real hardware intercept.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
gt; cached in the TLB.
>
> This is a performance optimisation.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Boris Ostrovsky
> ---
> CC: Jan Beulich
> CC: Tim Deegan
> CC: Wei Liu
> CC: Boris Ostrovsky
> CC: Suravee Suthikulpanit
>
> While being a perform
On 04/05/2016 09:25 PM, Boris Ostrovsky wrote:
> This is an RFC for making hvmloader's ACPI builder available to both the
> toolstack and the hypervisor, as discussed in
> http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01228.html
When do people think they will g
On 05/10/2016 03:23 AM, Jan Beulich wrote:
>>>> On 09.05.16 at 20:40, wrote:
>> On 05/09/2016 01:22 PM, Kevin Moraga wrote:
>>> On 05/09/2016 11:15 AM, Boris Ostrovsky wrote:
>>>> On 05/09/2016 12:40 PM, Kevin Moraga wrote:
>>>>> On 05/09/2016
x140
> [] ? finish_task_switch+0x76/0x220
> [] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20
> [] smpboot_thread_fn+0x105/0x160
> [] ? sort_range+0x30/0x30
> [] kthread+0xd8/0xf0
> [] ? kthread_create_on_node+0x1e0/0x1e0
> [] ret_from_fork+0x3f/0x70
> [] ? kthread
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 10/05/16 15:57, Jan Beulich wrote:
>>> On 10.05.16 at 15:39, wrote:
> I didn't finish unwrapping the stack yesterday. Here it is:
>
> setup_arch -> dmi_sc
On 05/10/2016 12:11 PM, Kevin Moraga wrote:
>
Can you boot your system bare-metal and post output of 'biosdecode' command?
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 05/16/2016 07:23 AM, Stefano Stabellini wrote:
> On Wed, 27 Apr 2016, Boris Ostrovsky wrote:
>> On 04/27/2016 09:40 AM, David Vrabel wrote:
>>> On 27/04/16 14:38, Boris Ostrovsky wrote:
>>>> int xen_nr_legacy_irqs()
>>>> {
>>>> if
On 05/16/2016 01:44 PM, David Vrabel wrote:
> "Fix" /proc/xen/xenbus by making it a symlink to the working
> /dev/xen/xenbus. Do the same for /proc/xen/privcmd so it matches.
>
> If there's agreement on this approach I'll resend to Cc the fs
> maintainers.
Looks good to me.
-boris
On 05/16/2016 05:38 PM, Tony S wrote:
> The issue behind it is that the process execution calculation(e.g.,
> delta_exec) in virtualized environment should not be calculated as it
> did in physical enviroment.
>
> Here are two solutions to fix it:
>
> 1) Based on the vcpu->runstate.time(running/run
Saving a guest (xl save) crashes dom0, log below.
Paul, this seems to be happening in the code that you modified
recently. If you don't have time I can look at this but it will
probably have to wait until tomorrow.
-boris
[ 176.347760] BUG: unable to handle kernel NULL pointer dereference at
On 05/18/2016 08:15 AM, Juergen Gross wrote:
> }
>
> +void __init xen_time_setup_guest(void)
> +{
> + pv_time_ops.steal_clock = xen_steal_clock;
> +
> + static_key_slow_inc(¶virt_steal_enabled);
> + /*
> + * We can't set paravirt_steal_rq_enabled as this would require the
> +
On 05/18/2016 10:27 AM, Paul Durrant wrote:
> This should fix the problem for you:
Yes, that does it. Thanks.
-boris
>
> diff --git a/drivers/net/xen-netback/interface.c
> b/drivers/net/xen-netback/interface.c
> index 1c7f49b..83deeeb 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b
On 05/18/2016 10:53 AM, Juergen Gross wrote:
> On 18/05/16 16:46, Boris Ostrovsky wrote:
>> On 05/18/2016 08:15 AM, Juergen Gross wrote:
>>> }
>>>
>>> +void __init xen_time_setup_guest(void)
>>> +{
>>> + pv_time_ops.steal_cloc
On 05/18/2016 11:45 AM, David Vrabel wrote:
> On 18/05/16 16:42, Juergen Gross wrote:
>> On 18/05/16 17:25, Boris Ostrovsky wrote:
>>> On 05/18/2016 10:53 AM, Juergen Gross wrote:
>>>> On 18/05/16 16:46, Boris Ostrovsky wrote:
>>>>>
On 05/18/2016 12:00 PM, Juergen Gross wrote:
> On 18/05/16 17:53, Boris Ostrovsky wrote:
>> On 05/18/2016 11:45 AM, David Vrabel wrote:
>>> On 18/05/16 16:42, Juergen Gross wrote:
>>>> On 18/05/16 17:25, Boris Ostrovsky wrote:
>>>>> On 05/18/2016 10:5
On 05/18/2016 12:10 PM, Dario Faggioli wrote:
> On Wed, 2016-05-18 at 16:53 +0200, Juergen Gross wrote:
>> On 18/05/16 16:46, Boris Ostrovsky wrote:
>>>
>>> Won't we be accounting for stolen cycles twice now --- once from
>>> steal_account_process_t
;t
> able to run due to hypervisor scheduling.
>
> Add support in Xen arch independent time handling for this feature by
> moving it out of the arm arch into drivers/xen and remove the x86 Xen
> hack.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
I think this also nee
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 accesses to IO space.
QEMU needs to be able to handle them.
Signed-off-by: Boris Ostrovsky
---
: boris.ostrov...@oracle.com
CC: jgr...@suse.com
CC: Julien Grall
Reviewed-by: Boris Ostrovsky
(+Konrad)
---
drivers/xen/swiotlb-xen.c | 8
include/xen/arm/page-coherent.h | 20 ++--
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/xen
On 04/14/2017 05:17 AM, Greg KH wrote:
> On Thu, Apr 13, 2017 at 03:06:53PM +0200, Juergen Gross wrote:
>> Revert commit 72a9b186292 ("xen: Remove event channel notification
>> through Xen PCI platform device") as the original analysis was wrong
>> that all the removed code isn't in use any more.
>
Add a debug Kconfig option that will make page allocator verify
that pages that were supposed to be scrubbed are, in fact, clean.
Signed-off-by: Boris Ostrovsky
---
xen/Kconfig.debug |7 ++
xen/common/page_alloc.c | 49 ++-
2 files
. so that it's easy to find pages that need to be scrubbed (those pages are
now marked with _PGC_need_scrub bit).
Signed-off-by: Boris Ostrovsky
---
Changes in v3:
* Keep dirty bit per page, add dirty_head to page_info that indicates whether
the buddy has dirty pages.
*
ber checks this bit after
processing each page and stops its work as soon as it sees it.
Signed-off-by: Boris Ostrovsky
---
Changes in v3:
* Adjusted page_info's scrub_state definitions but kept them as binary
flags since I think having both PAGE_SCRUBBING and PAGE_SCRUB_ABORT
bits set ma
Instead of scrubbing pages during guest destruction (from
free_heap_pages()) do this opportunistically, from the idle loop.
Signed-off-by: Boris Ostrovsky
---
Changes in v3:
* If memory-only nodes exist, select the closest one for scrubbing
* Don't scrub from idle loop until we
de.
Deferred:
* Per-node heap locks. In addition to (presumably) improving performance in
general, once they are available we can parallelize scrubbing further by
allowing more than one core per node to do idle loop scrubbing.
* AVX-based scrubbing
* Use idle loop scrubbing during boot.
Boris
from free_heap_pages() and
instead do it from idle loop.
Signed-off-by: Boris Ostrovsky
---
xen/common/page_alloc.c | 96 ++
1 files changed, 71 insertions(+), 25 deletions(-)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 9dcf6ee..055654d 1
ff-by: Boris Ostrovsky
---
xen/common/page_alloc.c | 78 ++
1 files changed, 64 insertions(+), 14 deletions(-)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index fcd7308..0b2dff1 100644
--- a/xen/common/page_alloc.c
+++ b/xen/c
ke up the waiter.
Signed-off-by: Boris Ostrovsky
---
Changes in v3:
* Integrate smp_mb into spin_lock_kick()
xen/common/spinlock.c |9 -
xen/include/xen/spinlock.h |8
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/xen/common/spinlock.c b/xen/c
This is needed for subsequent changes to memory scrubbing.
Signed-off-by: Boris Ostrovsky
---
Changes in v3:
* Simplify merge_and_free_buddy() (and drop can_merge())
xen/common/page_alloc.c | 74 ++-
1 files changed, 41 insertions(+), 33 deletions
Signed-off-by: Boris Ostrovsky
Reviewed-by: Wei Liu
---
xen/common/page_alloc.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 514a4a1..dd6f248 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common
On 04/18/2017 02:49 AM, Jan Beulich wrote:
On 13.04.17 at 18:55, wrote:
>> On 04/13/2017 11:46 AM, Jan Beulich wrote:
>> On 03.04.17 at 18:50, wrote:
While waiting for a lock we may want to periodically run some
code. We could use spin_trylock() but since it doesn't take lock
>
On 04/18/2017 08:43 AM, Jan Beulich wrote:
On 18.04.17 at 14:32, wrote:
>> On 04/18/2017 02:49 AM, Jan Beulich wrote:
>> On 13.04.17 at 18:55, wrote:
On 04/13/2017 11:46 AM, Jan Beulich wrote:
On 03.04.17 at 18:50, wrote:
>> While waiting for a lock we may want to peri
On 04/19/2017 09:21 AM, Jan Beulich wrote:
On 19.04.17 at 06:56, wrote:
On Wed, Apr 19, 2017 at 02:48:57AM -0600, Jan Beulich wrote:
On 18.04.17 at 23:51, wrote:
HVM guest can't enable x2apic as XENFEAT_hvm_pirqs is exposed to it.
Why we have this restriction? As a consequence, This patch
the same base as is used in the vendor
>manuals (decimal for Intel, hex for AMD), and consistently use 0x for hex
>numbers.
>
> In particular, this corrects the information printed for nested VT-x, and
> actually prints information for nested SVM.
>
> Signed-off-
On 04/20/2017 11:40 AM, Vitaly Kuznetsov wrote:
> Peter Zijlstra writes:
>
>> On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote:
>>> In this patch I suggest we set __max_logical_packages based on the
>>> max_physical_pkg_id and total_cpus,
>> So my 4 socket 144 CPU system will then
On 04/20/2017 12:15 PM, Peter Zijlstra wrote:
> On Thu, Apr 20, 2017 at 05:40:37PM +0200, Vitaly Kuznetsov wrote:
>>> This is getting ludicrous. Xen is plain broken, and instead of fixing
>>> it, you propose to somehow deal with its obviously crack induced
>>> behaviour :-(
>> Totally agree and I d
e820 map is updated with information from the zeropage (i.e.
pvh_bootparams) by default_machine_specific_memory_setup().
With the way things are done now, we end up with a duplicated
e820 map.
Signed-off-by: Boris Ostrovsky
---
This patch is against for-linus-4.12 branch. Since this is not
a
> +static bool __init xen_check_xsave(void)
> {
> - unsigned int ax, bx, cx, dx;
> - unsigned int xsave_mask;
> + unsigned int err, eax, edx;
>
> - ax = 1;
> - cx = 0;
> - cpuid(1, &ax, &bx, &cx, &dx);
> + /* Test OSXSAVE capability via xgetbv instruction. */
> +
1 - 100 of 3023 matches
Mail list logo
