Hello Stefano,
On 27.11.18 23:27, Stefano Stabellini wrote:
Hi Andrii,
See the following:
https://marc.info/?l=xen-devel&m=148668817704668
Thank you for the point. I remember this email, but missed it also gives
details to setup the experiment. It looks that bare-metal app is not SoC
specifi
On 29/11/2018 02:22, Hans van Kranenburg wrote:
> Hi,
>
> As also seen at:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914951
>
> Attached there are two serial console output logs. One is starting with
> Xen 4.11 (from debian unstable) as dom0, and the other one without Xen.
>
> [2.0
Am 28.11.2018 um 17:40 hat Paul Durrant geschrieben:
> > -Original Message-
> > From: Kevin Wolf [mailto:kw...@redhat.com]
> > Sent: 28 November 2018 16:35
> > To: Paul Durrant
> > Cc: qemu-bl...@nongnu.org; qemu-de...@nongnu.org; xen-
> > de...@lists.xenproject.org; Stefano Stabellini ;
>
Am 28.11.2018 um 17:46 hat Paul Durrant geschrieben:
> > -Original Message-
> > From: Paul Durrant
> > Sent: 28 November 2018 16:46
> > To: 'Kevin Wolf'
> > Cc: 'Stefano Stabellini' ; qemu-bl...@nongnu.org;
> > qemu-de...@nongnu.org; xen-devel@lists.xenproject.org; Eduardo Habkost
> > ; Mi
On Thu, Nov 29, 2018 at 10:00:34AM +0800, Chao Gao wrote:
> On Wed, Nov 28, 2018 at 11:58:06AM +0100, Roger Pau Monné wrote:
> >On Wed, Nov 28, 2018 at 01:34:11PM +0800, Chao Gao wrote:
> >> static int microcode_sanity_check(void *mc)
> >> @@ -236,31 +259,13 @@ static int get_matching_microcode(co
On Thu, Nov 29, 2018 at 10:40:32AM +0800, Chao Gao wrote:
> On Wed, Nov 28, 2018 at 01:00:14PM +0100, Roger Pau Monné wrote:
> >On Wed, Nov 28, 2018 at 01:34:12PM +0800, Chao Gao wrote:
> >> ... and search caches to find a suitable one when loading.
> >
> >Why do you need to save all of them? You a
>>> On 28.11.18 at 18:48, wrote:
> On Wed, Nov 28, 2018 at 10:04:33AM -0700, Jan Beulich wrote:
>> >>> On 28.11.18 at 17:54, wrote:
>> > On Wed, Nov 28, 2018 at 09:22:16AM -0700, Jan Beulich wrote:
>> >> >>> On 28.11.18 at 16:41, wrote:
>> >> > My plan is that DomUs won't be allowed to toggle th
> -Original Message-
> From: Kevin Wolf [mailto:kw...@redhat.com]
> Sent: 29 November 2018 09:01
> To: Paul Durrant
> Cc: qemu-bl...@nongnu.org; qemu-de...@nongnu.org; xen-
> de...@lists.xenproject.org; Stefano Stabellini ;
> Anthony Perard ; Max Reitz
> Subject: Re: [PATCH 14/18] xen: ad
>>> On 28.11.18 at 01:05, wrote:
> update_runstate_area() using a virtual address is a complete misfeature,
> and the sooner we can replace it, the better. It's history is with x86
> PV guests, where the early ABIs were designed in terms of Linux's
> copy_{to,from}_user().
>
> It is similarly br
On 29/11/2018 02:22, Hans van Kranenburg wrote:
> Hi,
>
> As also seen at:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914951
>
> Attached there are two serial console output logs. One is starting with
> Xen 4.11 (from debian unstable) as dom0, and the other one without Xen.
>
> [2.0
On Thu, Nov 29, 2018 at 12:28:46PM +0800, Chao Gao wrote:
> On Wed, Nov 28, 2018 at 04:02:25PM +0100, Roger Pau Monné wrote:
> >On Wed, Nov 28, 2018 at 01:34:14PM +0800, Chao Gao wrote:
> >> diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c
> >> index 8350d22..cca7b2c 100644
> >> ---
On 29/11/2018 10:39, Jan Beulich wrote:
On 28.11.18 at 01:05, wrote:
>> update_runstate_area() using a virtual address is a complete misfeature,
>> and the sooner we can replace it, the better. It's history is with x86
>> PV guests, where the early ABIs were designed in terms of Linux's
>> c
On Thu, Nov 29, 2018 at 12:43:25PM +0800, Chao Gao wrote:
> On Wed, Nov 28, 2018 at 04:22:09PM +0100, Roger Pau Monné wrote:
> >On Wed, Nov 28, 2018 at 01:34:16PM +0800, Chao Gao wrote:
> >> This patch ports microcode improvement patches from linux kernel.
> >>
> >> Before you read any further: th
>>> On 28.11.18 at 22:56, wrote:
> Changes since V9:
> - Removed the patch RFC (replaced by a printk(XENLOG_G_WARNING).
> - Reused start and end in change_type_range() and removed the
>intermediary variables range_start and range_end.
> - Added an extra explanation for the if ( start > end
On 29/11/2018 09:39, Jan Beulich wrote:
On 28.11.18 at 01:05, wrote:
>> update_runstate_area() using a virtual address is a complete misfeature,
>> and the sooner we can replace it, the better. It's history is with x86
>> PV guests, where the early ABIs were designed in terms of Linux's
>> c
>>> On 28.11.18 at 22:56, wrote:
> change_range_type() invalidates gfn ranges to lazily change the type
> of a range of gfns, and also modifies the logdirty rangesets of that
> p2m. At the moment, it clips both down by the hostp2m.
>
> While this will result in correct behavior, it's not entirely
>>> On 29.11.18 at 11:03, wrote:
> Furthermore, looking at the content held in the runstate area, what do
> guests actually use the information for? It looks like it is of
> marginal use for diagnostics within the guest.
Correct steal time accounting, at the very least, depends on this
iirc. Ste
>>> On 29.11.18 at 03:40, wrote:
> On Wed, Nov 28, 2018 at 01:00:14PM +0100, Roger Pau Monné wrote:
>>On Wed, Nov 28, 2018 at 01:34:12PM +0800, Chao Gao wrote:
>>> @@ -491,6 +559,21 @@ static int cpu_request_microcode(unsigned int cpu,
>>> const void *buf,
>>> while ( (error = get_ucode_from
This run is configured for baseline tests only.
flight 75625 xen-4.11-testing real [real]
http://osstest.xensource.com/osstest/logs/75625/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1
Hi Andrii,
On 28/11/2018 21:32, Andrii Anisov wrote:
From: Andrii Anisov
Avoid excessive conversions between pending_irq and irq number/priority.
This simlifies functions interface and reduces under locks code size.
I was expecting the commit message to be updated based on the discussion we
On Thu, Nov 29, 2018 at 02:25:02AM -0700, Jan Beulich wrote:
> >>> On 28.11.18 at 18:48, wrote:
> > On Wed, Nov 28, 2018 at 10:04:33AM -0700, Jan Beulich wrote:
> >> >>> On 28.11.18 at 17:54, wrote:
> >> > On Wed, Nov 28, 2018 at 09:22:16AM -0700, Jan Beulich wrote:
> >> >> >>> On 28.11.18 at 16:
>>> On 29.11.18 at 11:25, wrote:
> On Thu, Nov 29, 2018 at 02:25:02AM -0700, Jan Beulich wrote:
>> >>> On 28.11.18 at 18:48, wrote:
>> > On Wed, Nov 28, 2018 at 10:04:33AM -0700, Jan Beulich wrote:
>> >> >>> On 28.11.18 at 17:54, wrote:
>> >> > On Wed, Nov 28, 2018 at 09:22:16AM -0700, Jan Beuli
Am 29.11.2018 um 10:33 hat Paul Durrant geschrieben:
> > -Original Message-
> > From: Kevin Wolf [mailto:kw...@redhat.com]
> > Sent: 29 November 2018 09:01
> > To: Paul Durrant
> > Cc: qemu-bl...@nongnu.org; qemu-de...@nongnu.org; xen-
> > de...@lists.xenproject.org; Stefano Stabellini ;
>
> -Original Message-
> From: Kevin Wolf [mailto:kw...@redhat.com]
> Sent: 29 November 2018 10:46
> To: Paul Durrant
> Cc: qemu-bl...@nongnu.org; qemu-de...@nongnu.org; xen-
> de...@lists.xenproject.org; Stefano Stabellini ;
> Anthony Perard ; Max Reitz
> Subject: Re: [PATCH 14/18] xen: ad
>>> On 28.11.18 at 17:46, wrote:
> I managed to compile and install Xen from source,using the stable-4.11
> branch.
>
> I configured my VMs in libvirt, but when I try to start one of them, the
> host completely crashes after a few seconds (the VM is never started), and
> reboots.
>
> I ran d
Hi,
On 29/11/2018 07:40, Andrii Anisov wrote:
Hello,
Again, I sent this cover letter only to myself. So, here it is, hope it does
not break the thread. Sorry for the mess.
It is seems to be part of the thread. Thank you!
From: Andrii Anisov
Sent: Wednesday, November 28, 2018 11:31 PM
C
flight 75626 distros-debian-wheezy real [real]
http://osstest.xensource.com/osstest/logs/75626/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 75617
jobs:
build-amd64 pass
build-armhf
On 28/11/2018 21:31, Andrii Anisov wrote:
From: Andrii Anisov
For GICV2 pending_irq allocation is not concurrent, so reduce
some code under lock.
So this is reverting part of 5f66da659060563df8481a86c017f07455095045
"ARM: vGIC: move irq_to_pending() calls under the VGIC VCPU lock".
The vGI
Hi Juergen,
I have noticed on the last few threads that your e-mails don't get threaded
correctly. Looking at the source, I can't find the In-Reply-To tag. Do you have
any issue with your e-mail?
On 29/11/2018 09:51, Juergen Gross wrote:
On 29/11/2018 10:39, Jan Beulich wrote:
On 28.11.18 at
ping
On 11/22/18 12:02 PM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
based frontends. Currently the frontends which implement
similar code for sharing big buffers between frontend and
backend are para-virtualized DRM and sound drivers.
Both define the same way to share grant
On Wed, Nov 28, 2018 at 05:43:33PM +, Wei Liu wrote:
> OVMF has become dependent on OpenSSL, which it is included as a submodule.
> Initialise submodules before building.
>
> Signed-off-by: Wei Liu
> ---
> This should fix the build breakage for OVMF branch in OSSTEST.
>
> Cc: Anthony PERARD
Hi all,
This patch series fixes 2 bug in the boot code for the memory management.
The first patch should resolve Xen stall when setting SCTLR.XN on some
platforms.
The second patch should allow to boot Xen again the Hikey board.
Cheers,
Cc: Shameerali Kolothum Thodi
Cc: Jan-Peter Larsson
Cc:
At the moment, Xen is relocated towards the end of the memory. While
this has the advantage to free space in low memory, the code is not
compliant with the break-before-make because it requires to switch
between two sets of page-table. This is not entirely trivial to fix as
it would require us to g
Xen mapping is first create using a 2MB page and then shatterred in 4KB
page for fine-graine permission. However, it is not safe to break-down
superpage page without going to an intermediate step invalidating
the entry.
As we are changing Xen mappings, we cannot go through the intermediate
step. T
Xen mapping is first create using a 2MB page and then shatterred in 4KB
page for fine-graine permission. However, it is not safe to break-down
superpage page without going to an intermediate step invalidating
the entry.
As we are changing Xen mappings, we cannot go through the intermediate
step. T
At the moment, Xen is relocated towards the end of the memory. While
this has the advantage to free space in low memory, the code is not
compliant with the break-before-make because it requires to switch
between two sets of page-table. This is not entirely trivial to fix as
it would require us to g
On Thu, Nov 29, 2018 at 11:31:41AM +, Anthony PERARD wrote:
> On Wed, Nov 28, 2018 at 05:43:33PM +, Wei Liu wrote:
> > OVMF has become dependent on OpenSSL, which it is included as a submodule.
> > Initialise submodules before building.
> >
> > Signed-off-by: Wei Liu
> > ---
> > This shou
> On Nov 28, 2018, at 6:33 PM, George Dunlap wrote:
>
>>> -ret = setresuid(dm_uid, dm_uid, 0);
>>> +fd = open(lockfile, O_RDWR|O_CREAT, 0666);
>>> +if (fd < 0) {
>>> +/* All other errno: EBADF, EINVAL, ENOLCK, EWOULDBLOCK */
>>> +LOGED(ERROR, domid
On Wed, Nov 28, 2018 at 09:50:33PM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 28, 2018 at 01:58:03PM +, Wei Liu wrote:
> > It is agreed that tmem can be removed from xen.git. See the thread starting
> >
> >
flight 130826 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130826/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken in 130773
build-arm64-pvops
On 11/29/18 12:07 PM, Jan Beulich wrote:
On 28.11.18 at 22:56, wrote:
>> change_range_type() invalidates gfn ranges to lazily change the type
>> of a range of gfns, and also modifies the logdirty rangesets of that
>> p2m. At the moment, it clips both down by the hostp2m.
>>
>> While this will
On Wed, Nov 28, 2018 at 03:57:58PM +, Anthony PERARD wrote:
> On Fri, Nov 23, 2018 at 05:18:59PM +, George Dunlap wrote:
> > On 11/23/18 5:15 PM, George Dunlap wrote:
> > Does libxl__qmp_cleanup() need to be called after the kill() happens?
> > If not, we could put this before the kill() an
On Mon, Nov 26, 2018 at 01:22:04PM +, Petre Eftime wrote:
> There is a circular link formed between domain and a connection. In certain
> circustances, when conn is freed, domain is also freed, which leads to use
circumstances.
> after free when trying to set the conn field in domain to null.
On Thu, Nov 29, 2018 at 11:39:54AM +, Wei Liu wrote:
> On Thu, Nov 29, 2018 at 11:31:41AM +, Anthony PERARD wrote:
> > What about the release tarball? Do we includes OVMF in it?
>
> Yes we do. But this should work because the Makefile is also shipped.
The fact that the Makefile is shipped
> On Nov 29, 2018, at 11:55 AM, Wei Liu wrote:
>
> On Wed, Nov 28, 2018 at 03:57:58PM +, Anthony PERARD wrote:
>> On Fri, Nov 23, 2018 at 05:18:59PM +, George Dunlap wrote:
>>> On 11/23/18 5:15 PM, George Dunlap wrote:
>>> Does libxl__qmp_cleanup() need to be called after the kill() hap
On Thu, 29 Nov 2018 07:40:00 +
Andrii Anisov wrote:
> Hello,
>
> Again, I sent this cover letter only to myself. So, here it is, hope
> it does not break the thread. Sorry for the mess.
>
>
> From: Andrii Anisov
> Sent: Wednesday, November 28, 2018 11:31 PM
> Cc: Andrii Anisov
> Subject:
On Wed, 28 Nov 2018 23:31:57 +0200
Andrii Anisov wrote:
Hi,
> From: Andrii Anisov
>
> This reduces some code and conditions in an IRQ processing path,
> and opens way to further code reduction.
While I understand that this is some sort of a hack, I am commenting
just on this patch to demonstr
On Wed, Nov 28, 2018 at 02:55:21PM +0100, Juergen Gross wrote:
> Add the needed code to setup the hypercall page for calling into the
> Xen hypervisor.
>
> Import the XEN_HVM_DEBUGCONS_IOPORT define from Xen unstable into
> include/xen/arch-x86/xen.h
>
> Signed-off-by: Juergen Gross
> Reviewed-by:
On Wed, 28 Nov 2018 23:32:05 +0200
Andrii Anisov wrote:
Hi,
> From: Andrii Anisov
>
> All bit operations for gic, vgic and gic-vgic are performed under
> spinlocks, so there is no need for atomic bit ops here, they only
> introduce excessive call to functions used more expensive exclusive
> AR
On Wed, Nov 28, 2018 at 11:21:54PM +0100, Hans van Kranenburg wrote:
> On 11/28/18 2:55 PM, Juergen Gross wrote:
> > From: Hans van Kranenburg
> >
> > This solves the build failing with "Error: no symbol table and no
> > .moddeps section"
> >
> > Also see:
> > - 6371e9c10433578bb236a8284ddb9ce9e20
The problem is that we call this with a spin lock held.
The call tree is:
pvcalls_front_accept() holds bedata->socket_lock.
-> create_active()
-> __get_free_pages() uses GFP_KERNEL
The create_active() function is only called from pvcalls_front_accept()
with a spin_lock held, The alloca
George Dunlap writes ("Re: [PATCH 3/9] libxl: Get rid of support for
QEMU_USER_BASE (xen-qemuuser-domidNN)"):
> I’d personally just as soon leave it out (and add it back in if someone asks
> for it), but if you think it has value I can leave it in and do the work of
> thinking about the logic.
George Dunlap writes ("Re: [PATCH 4/9] dm_depriv: Describe expected usage of
device_model_user parameter"):
> Because the feature is already implemented and working correctly according to
> the pre-series semantics (AFAICT), but not documented (other than a comment
> in libxl_types.idl saying, “
On Wed, Nov 28, 2018 at 02:55:10PM +0100, Juergen Gross wrote:
> This patch series adds support for booting Linux as PVH guest.
>
> Similar to i386/xen and x86_64/xen platforms the new i386/xenpvh
> platform grub is booted as a standalone image directly by Xen.
>
> For booting Linux kernel it is us
George Dunlap writes ("Re: [PATCH 8/9] libxl: Kill QEMU by uid when possible"):
> It wouldn’t be terribly hard to have a common “exit” to both the
> kill-by-pid and kill-by-uid paths that did it once, but it would
> involve adding Yet Another Function; and each additional function
> makes the code
> On Nov 29, 2018, at 12:26 PM, Ian Jackson wrote:
>
> George Dunlap writes ("Re: [PATCH 8/9] libxl: Kill QEMU by uid when
> possible"):
>> It wouldn’t be terribly hard to have a common “exit” to both the
>> kill-by-pid and kill-by-uid paths that did it once, but it would
>> involve adding Yet
Hi Daniel,
On 11/29/18 1:22 PM, Daniel Kiper wrote:
> On Wed, Nov 28, 2018 at 02:55:10PM +0100, Juergen Gross wrote:
>> This patch series adds support for booting Linux as PVH guest.
>>
>> Similar to i386/xen and x86_64/xen platforms the new i386/xenpvh
>> platform grub is booted as a standalone i
On Mon, Nov 26, 2018 at 01:22:04PM +, Petre Eftime wrote:
> There is a circular link formed between domain and a connection. In certain
> circustances, when conn is freed, domain is also freed, which leads to use
> after free when trying to set the conn field in domain to null.
Actually, can y
There is a circular link formed between domain and a connection. Under certain
circumstances, when conn is freed, domain is also freed, which leads to use
after free when trying to set the conn field in domain to null.
Signed-off-by: Petre Eftime
---
tools/xenstore/xenstored_domain.c | 9 +++
Ping? Can I get an ack or otherwise from an AMD maintainer please?
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 26 November 2018 11:33
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Suravee Suthikulpanit
> ; Brian Woods
> Subject: [PATCH v2
Ping? Can I get an ack or otherwise from an AMD maintainer please?
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 26 November 2018 11:33
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Suravee Suthikulpanit
> ; Brian Woods
> Subject: [PATCH v2
On Thu, Nov 29, 2018 at 01:40:35PM +0100, Hans van Kranenburg wrote:
> Hi Daniel,
>
> On 11/29/18 1:22 PM, Daniel Kiper wrote:
> > On Wed, Nov 28, 2018 at 02:55:10PM +0100, Juergen Gross wrote:
> >> This patch series adds support for booting Linux as PVH guest.
> >>
> >> Similar to i386/xen and x86
On Thu, Nov 29, 2018 at 12:02:16PM +, Anthony PERARD wrote:
> On Thu, Nov 29, 2018 at 11:39:54AM +, Wei Liu wrote:
> > On Thu, Nov 29, 2018 at 11:31:41AM +, Anthony PERARD wrote:
> > > What about the release tarball? Do we includes OVMF in it?
> >
> > Yes we do. But this should work be
I didn't go extremely deep in my debugging, as the talloc library is a bit
difficult to debug, but under the do_introduce function you have these
two lines:
/* Now domain belongs to its connection. */
talloc_steal(domain->conn, domain);
After these happen, destro
Thanks Andrew and Ian for taking the time to look at this change.
In turn it took me some time to get back to this topic.
Am Mon, 1 Oct 2018 13:39:51 +0100
schrieb Andrew Cooper :
> On 07/06/18 14:08, Olaf Hering wrote:
> > Add an option to control when vTSC emulation will be activated for a
> >
On 11/29/18 12:04 PM, Jan Beulich wrote:
On 28.11.18 at 22:56, wrote:
>> Changes since V9:
>> - Removed the patch RFC (replaced by a printk(XENLOG_G_WARNING).
>> - Reused start and end in change_type_range() and removed the
>>intermediary variables range_start and range_end.
>> - Added
On Thu, Nov 29, 2018 at 09:41:25AM +, Juergen Gross wrote:
> On 29/11/2018 02:22, Hans van Kranenburg wrote:
> > Hi,
> >
> > As also seen at:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914951
> >
> > Attached there are two serial console output logs. One is starting with
> > Xen 4.
Roger,
in the context of some other bug report here I've been pointed
at Linux commit 6af7e4f77259ee946103387372cb159f2e99a6d4.
I think we will need to implement something similar for any
devices that may be present on x86 systems, but don't have
standard compliant behavior of registers in what no
>>> On 29.11.18 at 13:53, wrote:
> Ping? Can I get an ack or otherwise from an AMD maintainer please?
Brian did ack this one, which I've committed yesterday, but not 2.
Jan
>> -Original Message-
>> From: Paul Durrant [mailto:paul.durr...@citrix.com]
>> Sent: 26 November 2018 11:33
>> To
On 29/11/2018 14:26, Kirill A. Shutemov wrote:
> On Thu, Nov 29, 2018 at 09:41:25AM +, Juergen Gross wrote:
>> On 29/11/2018 02:22, Hans van Kranenburg wrote:
>>> Hi,
>>>
>>> As also seen at:
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914951
>>>
>>> Attached there are two serial cons
On Thu, Nov 29, 2018 at 01:10:52PM +, Eftime, Petre wrote:
> I didn't go extremely deep in my debugging, as the talloc library is a bit
> difficult to debug, but under the do_introduce function you have these
> two lines:
difficult to debug> I completely agree. ;-)
>
> /* No
On Thu, Nov 29, 2018 at 03:41:07AM -0700, Jan Beulich wrote:
> >>> On 29.11.18 at 11:25, wrote:
> > On Thu, Nov 29, 2018 at 02:25:02AM -0700, Jan Beulich wrote:
> >> >>> On 28.11.18 at 18:48, wrote:
> >> > On Wed, Nov 28, 2018 at 10:04:33AM -0700, Jan Beulich wrote:
> >> >> >>> On 28.11.18 at 17:
On Thu, Nov 29, 2018 at 01:38:11PM +, Wei Liu wrote:
> On Thu, Nov 29, 2018 at 01:10:52PM +, Eftime, Petre wrote:
> > I didn't go extremely deep in my debugging, as the talloc library is a bit
> > difficult to debug, but under the do_introduce function you have these
> > two lines:
>
> dif
>>> On 29.11.18 at 14:23, wrote:
> On 11/29/18 12:04 PM, Jan Beulich wrote:
> On 28.11.18 at 22:56, wrote:
>>> Changes since V9:
>>> - Removed the patch RFC (replaced by a printk(XENLOG_G_WARNING).
>>> - Reused start and end in change_type_range() and removed the
>>>intermediary variabl
Hi Julien,
On Tue, Nov 27, 2018 at 7:36 PM Julien Grall wrote:
>
>
>
> On 11/17/18 4:01 PM, Mirela Simonovic wrote:
> > Hi,
>
> Hi Mirela,
>
> >
> > On Sat, Nov 17, 2018 at 12:06 AM Stefano Stabellini
> > wrote:
> >>
> >> On Sat, 17 Nov 2018, Dario Faggioli wrote:
> >>> On Fri, 2018-11-16 at 21:
On 21/11/18 16:12, Paul Durrant wrote:
> I have made many significant contributions to the Xen code in QEMU,
> particularly the recent patches introducing a new PV device framework.
> I intend to make further significant contributions, porting other PV back-
> ends to the new framework with the int
> -Original Message-
> From: Philippe Mathieu-Daudé [mailto:phi...@redhat.com]
> Sent: 29 November 2018 14:01
> To: Paul Durrant ; qemu-bl...@nongnu.org; qemu-
> de...@nongnu.org; xen-devel@lists.xenproject.org
> Cc: Anthony Perard ; Paolo Bonzini
> ; Stefano Stabellini
> Subject: Re: [Qem
4.4-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit b3681dd548d06deb2e1573890829dff4b15abf46 ]
error_entry and error_exit communicate the user vs. kernel status of
the frame using %ebx. This is unnecessary -- the information is in
reg
On Thu, Nov 29, 2018 at 01:35:17PM +, Juergen Gross wrote:
> On 29/11/2018 14:26, Kirill A. Shutemov wrote:
> > On Thu, Nov 29, 2018 at 09:41:25AM +, Juergen Gross wrote:
> >> On 29/11/2018 02:22, Hans van Kranenburg wrote:
> >>> Hi,
> >>>
> >>> As also seen at:
> >>> https://bugs.debian.or
On Thu, Nov 29, 2018 at 01:35:17PM +, Juergen Gross wrote:
> On 29/11/2018 14:26, Kirill A. Shutemov wrote:
> > On Thu, Nov 29, 2018 at 09:41:25AM +, Juergen Gross wrote:
> >> On 29/11/2018 02:22, Hans van Kranenburg wrote:
> >>> Hi,
> >>>
> >>> As also seen at:
> >>> https://bugs.debian.or
>>> On 29.11.18 at 14:44, wrote:
> I cannot see how interactions with a device with half-mapped BARs
> could trigger aborts that cannot be triggered when the device has
> fully mapped BARs. Ie: if there's indeed a way to trigger such aborts
> it would also be possible to do so with fully mapped BA
On Thu, Nov 29, 2018 at 02:24:47PM +, Kirill A. Shutemov wrote:
> On Thu, Nov 29, 2018 at 01:35:17PM +, Juergen Gross wrote:
> > On 29/11/2018 14:26, Kirill A. Shutemov wrote:
> > > On Thu, Nov 29, 2018 at 09:41:25AM +, Juergen Gross wrote:
> > >> On 29/11/2018 02:22, Hans van Kranenbur
On Thu, Nov 08, 2018 at 09:17:06AM -0700, Jan Beulich wrote:
> This is intentionally not touching hooks used rarely (or not at all)
> during the lifetime of a VM, unless perhaps sitting on an error path
> next to a call which gets changed (in which case I think the error
> path better remains consi
We've had more than one report of host crashes after failed migration,
and in at least one case we've had a hint towards a too far shrunk
shadow allocation pool. Instead of just checking the pool for being
empty, check whether the pool is smaller than what
shadow_set_allocation() would minimally bu
On Thu, Nov 08, 2018 at 09:05:45AM -0700, Jan Beulich wrote:
> We don't need bigger alignment except when calling EFI boot or runtime
> services functions (and we don't guarantee that either, as explained
> close to the top of xen/common/efi/runtime.c in the struct efi_rs_state
> declaration). Henc
On Wed, 2018-11-28 at 21:24 +0200, Razvan Cojocaru wrote:
> On 11/28/18 5:29 PM, Petre Pircalabu wrote:
> > Signed-off-by: Petre Pircalabu
> > ---
> >
> > +static int xenaccess_evtchn_bind(xenaccess_t *xenaccess)
> > +{
> +int rc, i = 0;
> > +
> > +rc = xenaccess_evtchn_bind_port(xenacces
On 29/11/2018 15:32, Kirill A. Shutemov wrote:
> On Thu, Nov 29, 2018 at 02:24:47PM +, Kirill A. Shutemov wrote:
>> On Thu, Nov 29, 2018 at 01:35:17PM +, Juergen Gross wrote:
>>> On 29/11/2018 14:26, Kirill A. Shutemov wrote:
On Thu, Nov 29, 2018 at 09:41:25AM +, Juergen Gross wrot
>>> On 29.11.18 at 15:54, wrote:
> On Thu, Nov 08, 2018 at 09:05:45AM -0700, Jan Beulich wrote:
>> We don't need bigger alignment except when calling EFI boot or runtime
>> services functions (and we don't guarantee that either, as explained
>> close to the top of xen/common/efi/runtime.c in the s
On Thu, Nov 29, 2018 at 03:00:45PM +, Juergen Gross wrote:
> On 29/11/2018 15:32, Kirill A. Shutemov wrote:
> > On Thu, Nov 29, 2018 at 02:24:47PM +, Kirill A. Shutemov wrote:
> >> On Thu, Nov 29, 2018 at 01:35:17PM +, Juergen Gross wrote:
> >>> On 29/11/2018 14:26, Kirill A. Shutemov w
On Mon, Nov 26, 2018 at 11:32:53AM +, Paul Durrant wrote:
> ...for N in {8, 16, 32, 64}.
>
> Bring the coding style up to date.
>
> Also, while in the neighbourhood, fix some tabs and remove use of uint64_t
> values where it leads to the need for explicit casting.
>
> Signed-off-by: Paul Dur
On Tue, Nov 27, 2018 at 04:24:41PM +0100, Roger Pau Monne wrote:
> Bridges are not behind an IOMMU, and are already special cased and
> skipped in amd_iommu_add_device. Apply the same special casing when
> updating page tables.
>
> This is required or else update_paging_mode will fail and return a
On Tue, Nov 27, 2018 at 04:24:40PM +0100, Roger Pau Monne wrote:
> AMD IOMMU devices are exposed on the PCI bus, and thus are assigned by
> default to the hardware domain. This can cause issues because the
> IOMMU devices themselves are not behind an IOMMU, so update_paging_mode will
> return an er
Hi Andrii,
On 28/11/2018 21:32, Andrii Anisov wrote:
From: Andrii Anisov
Simplify context restore from idle vcpu to the one ran before it.
This improves low cpu load but high irq rate use-cases.
While I agree that the context switch today is pretty inefficient, I would be
interest to know h
FYI the To: field is empty for your patch.
On Wed, Nov 28, 2018 at 11:32:09PM +0200, Andrii Anisov wrote:
[...]
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -272,6 +272,7 @@ struct vcpu
> struct vpci_vcpu vpci;
>
> struct arch_vcpu arch;
> +struct vcpu *prev
On Wed, Nov 28, 2018 at 12:02:21AM +0400, Marc-André Lureau wrote:
> Hi
>
> On Tue, Nov 27, 2018 at 11:40 PM Eduardo Habkost wrote:
> >
> > On Tue, Nov 27, 2018 at 01:27:48PM +0400, Marc-André Lureau wrote:
> > > Introduce object_apply_global_props() function, to apply compatibility
> > > propert
On Wed, Nov 21, 2018 at 03:11:56PM +, Paul Durrant wrote:
> This patch adds a new XenDevice: 'xen-qdisk' [1]. This will eventually
> replace the 'xen_disk' legacy PV backend but it is illustrative to build
> up the implementation incrementally, along with the XenBus/XenDevice
> framework. Subse
Hi,
On 29/11/2018 12:14, Andre Przywara wrote:
On Wed, 28 Nov 2018 23:32:05 +0200
Andrii Anisov wrote:
Hi,
From: Andrii Anisov
All bit operations for gic, vgic and gic-vgic are performed under
spinlocks, so there is no need for atomic bit ops here, they only
introduce excessive call to fun
On Wed, Nov 28, 2018 at 11:19:15AM -0800, Linus Torvalds wrote:
> Let me just paste it back in here:
>
> "Which is what we ALREADY do for these exact reasons. If the DMA
> mappings means that you'd need to add one more page to that list of
> reserved pages, then so be it."
>
> So no, I'm not at
On 28/11/2018 21:32, Andrii Anisov wrote:
From: Andrii Anisov
Cache line size assumed 64 byte as for H3. Align the `struct
pending_irq` and allocate lrs shadow aligned to cache line size.
The arch_vcpu is already aligned to a cache size. So how does it improve the
performance by making lr
On 28/11/2018 21:32, Andrii Anisov wrote:
From: Andrii Anisov
This saves one write to peripheral HCR register per hypervisor entry for
most cases.
Signed-off-by: Andrii Anisov
---
xen/arch/arm/gic-v2.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/xen/arch/ar
1 - 100 of 142 matches
Mail list logo
