Re: [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation]

On Fri, Jun 19, 2020 at 11:43:12PM +, Anchal Agarwal wrote: > On Wed, Jun 17, 2020 at 10:35:28AM +0200, Roger Pau Monné wrote: > > CAUTION: This email originated from outside of the organization. Do not > > click links or open attachments unless you can confirm the

Re: [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation]

On Tue, Jun 16, 2020 at 10:30:03PM +, Anchal Agarwal wrote: > On Tue, Jun 16, 2020 at 09:49:25PM +, Anchal Agarwal wrote: > > On Thu, Jun 04, 2020 at 09:05:48AM +0200, Roger Pau Monné wrote: > > > On Wed, Jun 03, 2020 at 11:33:52PM +, Agarwal, Anchal wrote: > >

Re: [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation]

On Tue, Jun 16, 2020 at 09:49:25PM +, Anchal Agarwal wrote: > On Thu, Jun 04, 2020 at 09:05:48AM +0200, Roger Pau Monné wrote: > > CAUTION: This email originated from outside of the organization. Do not > > click links or open attachments unless you can confirm the

Re: [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation]

Hello, On Wed, Jun 03, 2020 at 11:33:52PM +, Agarwal, Anchal wrote: > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you can confirm the sender and know > the content is safe. > > > > On Tue, May 19, 2020 at

Re: [BOOTLOADER SPECIFICATION RFC] The bootloader log format for TrenchBoot and others

On Fri, May 29, 2020 at 01:27:35PM +0200, Daniel Kiper wrote: > Hey, > > Below you can find my rough idea of the bootloader log format which is > generic thing but initially will be used for TrenchBoot work. I discussed > this proposal with Ross and Daniel S. So, the idea went through initial >

Re: [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation

On Tue, May 19, 2020 at 11:27:50PM +, Anchal Agarwal wrote: > From: Munehisa Kamata > > S4 power transition states are much different than xen > suspend/resume. Former is visible to the guest and frontend drivers should > be aware of the state transitions and should be able to take

Re: [Xen-devel] xen/evtchn and forced threaded irq

On Tue, Feb 26, 2019 at 10:26:21AM +, Julien Grall wrote: > Hi, > > On 26/02/2019 10:17, Roger Pau Monné wrote: > > On Tue, Feb 26, 2019 at 10:03:38AM +, Julien Grall wrote: > > > Hi Roger, > > > > > > On 26/02/2019 09:44, Roger Pau Monné wrote:

Re: [Xen-devel] xen/evtchn and forced threaded irq

On Tue, Feb 26, 2019 at 10:03:38AM +, Julien Grall wrote: > Hi Roger, > > On 26/02/2019 09:44, Roger Pau Monné wrote: > > On Tue, Feb 26, 2019 at 09:30:07AM +, Andrew Cooper wrote: > > > On 26/02/2019 09:14, Roger Pau Monné wrote: > > > > On Mon, Feb

Re: [Xen-devel] xen/evtchn and forced threaded irq

On Tue, Feb 26, 2019 at 09:30:07AM +, Andrew Cooper wrote: > On 26/02/2019 09:14, Roger Pau Monné wrote: > > On Mon, Feb 25, 2019 at 01:55:42PM +, Julien Grall wrote: > >> Hi Oleksandr, > >> > >> On 25/02/2019 13:24, Oleksandr Andrushchenko wrote: &g

Re: [Xen-devel] xen/evtchn and forced threaded irq

On Mon, Feb 25, 2019 at 01:55:42PM +, Julien Grall wrote: > Hi Oleksandr, > > On 25/02/2019 13:24, Oleksandr Andrushchenko wrote: > > On 2/22/19 3:33 PM, Julien Grall wrote: > > > Hi, > > > > > > On 22/02/2019 12:38, Oleksandr Andrushchenko wrote: > > > > On 2/20/19 10:46 PM, Julien Grall

Re: [Xen-devel] xen/evtchn and forced threaded irq

On Thu, Feb 21, 2019 at 08:38:39AM +, Julien Grall wrote: > Hi Roger, > > On Thu, 21 Feb 2019, 08:08 Roger Pau Monné, wrote: > > > FWIW, you can also mask the interrupt while waiting for the thread to > > execute the interrupt handler. Ie: > > > > Th

Re: [Xen-devel] xen/evtchn and forced threaded irq

On Wed, Feb 20, 2019 at 10:03:57PM +, Julien Grall wrote: > Hi Boris, > > On 2/20/19 9:46 PM, Boris Ostrovsky wrote: > > On 2/20/19 3:46 PM, Julien Grall wrote: > > > (+ Andrew and Jan for feedback on the event channel interrupt) > > > > > > Hi Boris, > > > > > > Thank you for the your

Re: [Xen-devel] [PATCH 1/1] xen-blkback: do not wake up shutdown_wq after xen_blkif_schedule() is stopped

On Thu, Jan 17, 2019 at 10:10:00AM +0800, Dongli Zhang wrote: > Hi Roger, > > On 2019/1/16 下午10:52, Roger Pau Monné wrote: > > On Wed, Jan 16, 2019 at 09:47:41PM +0800, Dongli Zhang wrote: > >> There is no need to wake up xen_blkif_schedule() as kthread_stop() is able

Re: [PATCH 1/1] xen-blkback: do not wake up shutdown_wq after xen_blkif_schedule() is stopped

On Wed, Jan 16, 2019 at 09:47:41PM +0800, Dongli Zhang wrote: > There is no need to wake up xen_blkif_schedule() as kthread_stop() is able > to already wake up the kernel thread. > > Signed-off-by: Dongli Zhang > --- > drivers/block/xen-blkback/xenbus.c | 4 +--- > 1 file changed, 1

Re: [PATCH 1/1] xen-blkback: do not wake up shutdown_wq after xen_blkif_schedule() is stopped

On Wed, Jan 16, 2019 at 09:47:41PM +0800, Dongli Zhang wrote: > There is no need to wake up xen_blkif_schedule() as kthread_stop() is able > to already wake up the kernel thread. > > Signed-off-by: Dongli Zhang Reviewed-by: Roger Pau Monné kthread_stop waits for the thread to exit

Re: [Xen-devel] [PATCH v6 2/2] xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront

gt; xen_blkif_disconnect() when frontend is destroyed. > > This patch reworks connect_ring() to read xenstore 'ring-page-order' only > once. > > Signed-off-by: Dongli Zhang LGTM: Reviewed-by: Roger Pau Monné Thanks!

Re: [Xen-devel] [PATCH v4 2/2] xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront

On Tue, Jan 8, 2019 at 10:53 AM Dongli Zhang wrote: > > Hi Roger, > > On 01/07/2019 11:27 PM, Roger Pau Monné wrote: > > On Mon, Jan 07, 2019 at 10:07:34PM +0800, Dongli Zhang wrote: > >> > >> > >> On 01/07/2019 10:05 PM, Dongli Zhang wrote: > &

Re: [Xen-devel] [PATCH v4 2/2] xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront

On Mon, Jan 07, 2019 at 10:07:34PM +0800, Dongli Zhang wrote: > > > On 01/07/2019 10:05 PM, Dongli Zhang wrote: > > > > > > On 01/07/2019 08:01 PM, Roger Pau Monné wrote: > >> On Mon, Jan 07, 2019 at 01:35:59PM +0800, Dongli Zhang wrote: > >>>

Re: [PATCH v4 2/2] xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront

On Mon, Jan 07, 2019 at 01:35:59PM +0800, Dongli Zhang wrote: > The xenstore 'ring-page-order' is used globally for each blkback queue and > therefore should be read from xenstore only once. However, it is obtained > in read_per_ring_refs() which might be called multiple times during the >

Re: [PATCH v4 1/2] xen/blkback: add stack variable 'blkif' in connect_ring()

On Mon, Jan 07, 2019 at 01:35:58PM +0800, Dongli Zhang wrote: > As 'be->blkif' is used for many times in connect_ring(), the stack variable > 'blkif' is added to substitute 'be-blkif'. > > Suggested-by: Paul Durrant > Signed-off-by: Dongli Zhang Reviewed-by: Roger Pau Monné

Re: [Xen-devel] [PATCH v2 1/1] xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront

On Tue, Dec 18, 2018 at 11:29:16PM +0800, Dongli Zhang wrote: > > > On 12/18/2018 11:13 PM, Roger Pau Monné wrote: > > On Tue, Dec 18, 2018 at 07:31:59PM +0800, Dongli Zhang wrote: > >> Hi Roger, > >> > >> On 12/18/2018 05:33 PM, Roger Pau Monné wrote

Re: [Xen-devel] [PATCH v2 1/1] xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront

On Tue, Dec 18, 2018 at 07:31:59PM +0800, Dongli Zhang wrote: > Hi Roger, > > On 12/18/2018 05:33 PM, Roger Pau Monné wrote: > > On Tue, Dec 18, 2018 at 08:55:38AM +0800, Dongli Zhang wrote: > >> The xenstore 'ring-page-order' is used globally for each blkback queue a

Re: [Xen-devel] [PATCH v2 1/1] xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront

On Tue, Dec 18, 2018 at 10:33:00AM +0100, Roger Pau Monné wrote: > On Tue, Dec 18, 2018 at 08:55:38AM +0800, Dongli Zhang wrote: > > + for (i = 0; i < nr_grefs; i++) { > > + char ring_ref_name[RINGREF_NAME_LEN]; > > + > > + snprintf(ring_ref_nam

Re: [PATCH v2 1/1] xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront

gt; xen_blkif_disconnect() when frontend is destroyed. > > This patch reworks connect_ring() to read xenstore 'ring-page-order' only > once. > > Signed-off-by: Dongli Zhang > --- > Changed since v1: > * change the order of xenstore read in read_per_ring_refs

Re: [PATCH 1/1] xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront

On Fri, Dec 07, 2018 at 12:18:04PM +0800, Dongli Zhang wrote: > The xenstore 'ring-page-order' is used globally for each blkback queue and > therefore should be read from xenstore only once. However, it is obtained > in read_per_ring_refs() which might be called multiple times during the >

Re: [Xen-devel] [PATCH] drivers/block/xen-blkback/common.h: use DIV_ROUND_UP instead of reimplementing its function

Adding Julien how did the work to support XEN_PAGE_SIZE != PAGE_SIZE. On Wed, Sep 12, 2018 at 02:14:26AM -0600, Jan Beulich wrote: > >>> On 12.09.18 at 07:45, wrote: > > --- a/drivers/block/xen-blkback/common.h > > +++ b/drivers/block/xen-blkback/common.h > > @@ -65,7 +65,7 @@ > >

Re: [Xen-devel] [PATCH] drivers/block/xen-blkback/common.h: use DIV_ROUND_UP instead of reimplementing its function

Adding Julien how did the work to support XEN_PAGE_SIZE != PAGE_SIZE. On Wed, Sep 12, 2018 at 02:14:26AM -0600, Jan Beulich wrote: > >>> On 12.09.18 at 07:45, wrote: > > --- a/drivers/block/xen-blkback/common.h > > +++ b/drivers/block/xen-blkback/common.h > > @@ -65,7 +65,7 @@ > >

Re: [Xen-devel] [PATCH v2 1/5] xen/blkback: don't keep persistent grants too long

> > Instead of freeing only persistent grants until the threshold is > reached add a timestamp and remove all persistent grants not having > been in use for a minute. > > Signed-off-by: Juergen Gross Reviewed-by: Roger Pau Monné Thanks, Roger.

Re: [Xen-devel] [PATCH v2 1/5] xen/blkback: don't keep persistent grants too long

> > Instead of freeing only persistent grants until the threshold is > reached add a timestamp and remove all persistent grants not having > been in use for a minute. > > Signed-off-by: Juergen Gross Reviewed-by: Roger Pau Monné Thanks, Roger.

Re: [PATCH] xen/blkfront: remove unused macros

On Wed, Jul 25, 2018 at 09:42:07AM +0200, Juergen Gross wrote: > Remove some macros not used anywhere. > > Signed-off-by: Juergen Gross Acked-by: Roger Pau Monné Thanks, Roger.

Re: [PATCH] xen/blkfront: remove unused macros

On Wed, Jul 25, 2018 at 09:42:07AM +0200, Juergen Gross wrote: > Remove some macros not used anywhere. > > Signed-off-by: Juergen Gross Acked-by: Roger Pau Monné Thanks, Roger.

Re: [PATCH 4.4 119/268] xen/pirq: fix error path cleanup when binding MSIs

On Wed, Jun 13, 2018 at 07:48:50PM +0100, Ben Hutchings wrote: > On Wed, 2018-02-28 at 09:19 +, Roger Pau Monne wrote: > > From: Roger Pau Monne > > > > [ Upstream commit 910f8befdf5bccf25287d9f1743e3e546bcb7ce0 ] > > > > Current cleanup in the error

Re: [PATCH 4.4 119/268] xen/pirq: fix error path cleanup when binding MSIs

On Wed, Jun 13, 2018 at 07:48:50PM +0100, Ben Hutchings wrote: > On Wed, 2018-02-28 at 09:19 +, Roger Pau Monne wrote: > > From: Roger Pau Monne > > > > [ Upstream commit 910f8befdf5bccf25287d9f1743e3e546bcb7ce0 ] > > > > Current cleanup in the error

Re: [Xen-devel] [PATCH v2 1/3] xen/pvh: enable and set default MTRR type

On Wed, May 09, 2018 at 12:30:16PM +0100, Roger Pau Monné wrote: > On Wed, May 09, 2018 at 11:56:40AM +0100, Andrew Cooper wrote: > > On 09/05/18 11:21, Roger Pau Monne wrote: > > I'm not sure that setting the default MTRR type is going to be a > > clever idea in hindsight

Re: [Xen-devel] [PATCH v2 1/3] xen/pvh: enable and set default MTRR type

On Wed, May 09, 2018 at 12:30:16PM +0100, Roger Pau Monné wrote: > On Wed, May 09, 2018 at 11:56:40AM +0100, Andrew Cooper wrote: > > On 09/05/18 11:21, Roger Pau Monne wrote: > > I'm not sure that setting the default MTRR type is going to be a > > clever idea in hindsight

Re: [Xen-devel] [PATCH v2 1/3] xen/pvh: enable and set default MTRR type

On Wed, May 09, 2018 at 11:56:40AM +0100, Andrew Cooper wrote: > On 09/05/18 11:21, Roger Pau Monne wrote: > > On PVH MTRR is not initialized by the firmware (because there's no > > firmware), so the kernel is started with MTRR disabled which means all > > memory accesses a

Re: [Xen-devel] [PATCH v2 1/3] xen/pvh: enable and set default MTRR type

On Wed, May 09, 2018 at 11:56:40AM +0100, Andrew Cooper wrote: > On 09/05/18 11:21, Roger Pau Monne wrote: > > On PVH MTRR is not initialized by the firmware (because there's no > > firmware), so the kernel is started with MTRR disabled which means all > > memory accesses a

[PATCH v2 1/3] xen/pvh: enable and set default MTRR type

Xen was using WB as the default memory type instead of UC. Fix this by enabling MTRR and setting the default type to WB. Linux will use PAT to set the actual memory cache attributes. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> Signed-off-by: Roger Pau Monné <roger@c

[PATCH v2 1/3] xen/pvh: enable and set default MTRR type

Xen was using WB as the default memory type instead of UC. Fix this by enabling MTRR and setting the default type to WB. Linux will use PAT to set the actual memory cache attributes. Signed-off-by: Boris Ostrovsky Signed-off-by: Roger Pau Monné --- Cc: Boris Ostrovsky Cc: Juergen Gross Cc

[PATCH v2 2/3] xen/store: do not store local values in xen_start_info

There's no need to store the xenstore page or event channel in xen_start_info if they are locally initialized. This also fixes PVH local xenstore initialization due to the lack of xen_start_info in that case. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> Signed-off-by: Rog

[PATCH v2 0/3] xen/pvh: Dom0 support

should be used. Compile a Linux kernel with this patches and PVH support and add dom0=pvh to the Xen command line. The following message will be displayed during Dom0 boot by the Linux kernel if PVH mode is used: "Booting paravirtualized kernel on Xen PVH" Thanks, Roger. Roger Pau Monne (3):

[PATCH v2 2/3] xen/store: do not store local values in xen_start_info

There's no need to store the xenstore page or event channel in xen_start_info if they are locally initialized. This also fixes PVH local xenstore initialization due to the lack of xen_start_info in that case. Signed-off-by: Boris Ostrovsky Signed-off-by: Roger Pau Monné --- Cc: Boris Ostrovsky

[PATCH v2 0/3] xen/pvh: Dom0 support

should be used. Compile a Linux kernel with this patches and PVH support and add dom0=pvh to the Xen command line. The following message will be displayed during Dom0 boot by the Linux kernel if PVH mode is used: "Booting paravirtualized kernel on Xen PVH" Thanks, Roger. Roger Pau Monne (3):

[PATCH v2 3/3] xen: share start flags between PV and PVH

Use a global variable to store the start flags for both PV and PVH. This allows the xen_initial_domain macro to work properly on PVH. Note that ARM is also switched to use the new variable. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> Signed-off-by: Roger Pau Monné

[PATCH v2 3/3] xen: share start flags between PV and PVH

Use a global variable to store the start flags for both PV and PVH. This allows the xen_initial_domain macro to work properly on PVH. Note that ARM is also switched to use the new variable. Signed-off-by: Boris Ostrovsky Signed-off-by: Roger Pau Monné --- Cc: Boris Ostrovsky Cc: Juergen Gross

[PATCH 2/3] xen/store: do not store local values in xen_start_info

There's no need to store the xenstore page or event channel in xen_start_info if they are locally initialized. This also fixes PVH local xenstore initialization due to the lack of xen_start_info in that case. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> Signed-off-by: Rog

[PATCH 2/3] xen/store: do not store local values in xen_start_info

There's no need to store the xenstore page or event channel in xen_start_info if they are locally initialized. This also fixes PVH local xenstore initialization due to the lack of xen_start_info in that case. Signed-off-by: Boris Ostrovsky Signed-off-by: Roger Pau Monné --- Cc: Boris Ostrovsky

[PATCH 3/3] xen: share start flags between PV and PVH

Use a global variable to store the start flags for both PV and PVH. This allows the xen_initial_domain macro to work properly on PVH. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> Signed-off-by: Roger Pau Monné <roger@citrix.com> --- Cc: Boris Ostrovsky &

[PATCH 3/3] xen: share start flags between PV and PVH

Use a global variable to store the start flags for both PV and PVH. This allows the xen_initial_domain macro to work properly on PVH. Signed-off-by: Boris Ostrovsky Signed-off-by: Roger Pau Monné --- Cc: Boris Ostrovsky Cc: Juergen Gross Cc: xen-de...@lists.xenproject.org --- arch/x86/xen

[PATCH 1/3] xen/pvh: enable and set default MTRR type

Xen was using WB as the default memory type instead of UC. Fix this by enabling MTRR and setting the default type to WB. Linux will use PAT to set the actual memory cache attributes. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> Signed-off-by: Roger Pau Monné <roger@c

[PATCH 1/3] xen/pvh: enable and set default MTRR type

Xen was using WB as the default memory type instead of UC. Fix this by enabling MTRR and setting the default type to WB. Linux will use PAT to set the actual memory cache attributes. Signed-off-by: Boris Ostrovsky Signed-off-by: Roger Pau Monné --- Cc: Boris Ostrovsky Cc: Juergen Gross Cc

[PATCH 0/3] xen/pvh: Dom0 support

should be used. Compile a Linux kernel with this patches and PVH support and add dom0=pvh to the Xen command line. The following message will be displayed during boot by the Linux kernel if PVH mode is used: "Booting paravirtualized kernel on Xen PVH" Thanks, Roger. Roger Pau Monne (3):

[PATCH 0/3] xen/pvh: Dom0 support

should be used. Compile a Linux kernel with this patches and PVH support and add dom0=pvh to the Xen command line. The following message will be displayed during boot by the Linux kernel if PVH mode is used: "Booting paravirtualized kernel on Xen PVH" Thanks, Roger. Roger Pau Monne (3):

Re: [Xen-devel] [PATCH 6/6] xen-blkfront: prepare request locally, only then put it on the shared ring

On Tue, May 01, 2018 at 09:22:31AM +0100, Roger Pau Monné wrote: > On Mon, Apr 30, 2018 at 11:01:50PM +0200, Marek Marczykowski-Górecki wrote: > > struct request *req, > > - struct blkif_req

Re: [Xen-devel] [PATCH 6/6] xen-blkfront: prepare request locally, only then put it on the shared ring

On Tue, May 01, 2018 at 09:22:31AM +0100, Roger Pau Monné wrote: > On Mon, Apr 30, 2018 at 11:01:50PM +0200, Marek Marczykowski-Górecki wrote: > > struct request *req, > > - struct blkif_req

Re: [PATCH 6/6] xen-blkfront: prepare request locally, only then put it on the shared ring

On Mon, Apr 30, 2018 at 11:01:50PM +0200, Marek Marczykowski-Górecki wrote: > Do not reuse data which theoretically might be already modified by the > backend. This is mostly about private copy of the request > (info->shadow[id].req) - make sure the request saved there is really the > one just

Re: [PATCH 6/6] xen-blkfront: prepare request locally, only then put it on the shared ring

On Mon, Apr 30, 2018 at 11:01:50PM +0200, Marek Marczykowski-Górecki wrote: > Do not reuse data which theoretically might be already modified by the > backend. This is mostly about private copy of the request > (info->shadow[id].req) - make sure the request saved there is really the > one just

Re: [Xen-devel] [PATCH 4/4] xen/PVH: Remove reserved entry in PVH GDT

On Mon, Apr 30, 2018 at 12:23:39PM -0400, Boris Ostrovsky wrote: > And without it we can't use _BOOT_XX macros any longer so define new ones. Not being that familiar with Linux internals I'm not sure I see the benefit of this. Isn't there a risk that some other code is going to use the __BOOT_XX

Re: [Xen-devel] [PATCH 4/4] xen/PVH: Remove reserved entry in PVH GDT

On Mon, Apr 30, 2018 at 12:23:39PM -0400, Boris Ostrovsky wrote: > And without it we can't use _BOOT_XX macros any longer so define new ones. Not being that familiar with Linux internals I'm not sure I see the benefit of this. Isn't there a risk that some other code is going to use the __BOOT_XX

Re: [Xen-devel] [PATCH 1/4] xen/PVH: Replace GDT_ENTRY with explicit constant

On Mon, Apr 30, 2018 at 02:07:43PM -0400, Boris Ostrovsky wrote: > On 04/30/2018 12:57 PM, Roger Pau Monné wrote: > > On Mon, Apr 30, 2018 at 12:23:36PM -0400, Boris Ostrovsky wrote: > >> Latest binutils release (2.29.1) will no longer allow proper computation > >>

Re: [Xen-devel] [PATCH 1/4] xen/PVH: Replace GDT_ENTRY with explicit constant

On Mon, Apr 30, 2018 at 02:07:43PM -0400, Boris Ostrovsky wrote: > On 04/30/2018 12:57 PM, Roger Pau Monné wrote: > > On Mon, Apr 30, 2018 at 12:23:36PM -0400, Boris Ostrovsky wrote: > >> Latest binutils release (2.29.1) will no longer allow proper computation > >>

Re: [Xen-devel] [PATCH 1/4] xen/PVH: Replace GDT_ENTRY with explicit constant

On Mon, Apr 30, 2018 at 12:23:36PM -0400, Boris Ostrovsky wrote: > Latest binutils release (2.29.1) will no longer allow proper computation > of GDT entries on 32-bits, with warning: > > arch/x86/xen/xen-pvh.S: Assembler messages: > arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range

Re: [Xen-devel] [PATCH 1/4] xen/PVH: Replace GDT_ENTRY with explicit constant

On Mon, Apr 30, 2018 at 12:23:36PM -0400, Boris Ostrovsky wrote: > Latest binutils release (2.29.1) will no longer allow proper computation > of GDT entries on 32-bits, with warning: > > arch/x86/xen/xen-pvh.S: Assembler messages: > arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On Wed, Apr 18, 2018 at 01:39:35PM +0300, Oleksandr Andrushchenko wrote: > On 04/18/2018 01:18 PM, Paul Durrant wrote: > > > -Original Message- > > > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > > > Of Roger Pau Monné &

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On Wed, Apr 18, 2018 at 01:39:35PM +0300, Oleksandr Andrushchenko wrote: > On 04/18/2018 01:18 PM, Paul Durrant wrote: > > > -Original Message- > > > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > > > Of Roger Pau Monné &

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On Wed, Apr 18, 2018 at 11:01:12AM +0300, Oleksandr Andrushchenko wrote: > On 04/18/2018 10:35 AM, Roger Pau Monné wrote: > > On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote: > > > On 04/17/2018 11:57 PM, Dongwon Kim wrote: > > > > On Tue, Ap

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On Wed, Apr 18, 2018 at 11:01:12AM +0300, Oleksandr Andrushchenko wrote: > On 04/18/2018 10:35 AM, Roger Pau Monné wrote: > > On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote: > > > On 04/17/2018 11:57 PM, Dongwon Kim wrote: > > > > On Tue, Ap

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote: > On 04/17/2018 11:57 PM, Dongwon Kim wrote: > > On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote: > > > On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote: > 3.2 Backend exports dma-buf to xen-front >

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote: > On 04/17/2018 11:57 PM, Dongwon Kim wrote: > > On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote: > > > On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote: > 3.2 Backend exports dma-buf to xen-front >

Re: [PATCH v1] xen-blkfront: dynamic configuration of per-vbd resources

On Mon, Apr 02, 2018 at 01:42:32PM -0400, Konrad Rzeszutek Wilk wrote: > From: Bob Liu > > The current VBD layer reserves buffer space for each attached device based on > three statically configured settings which are read at boot time. > * max_indirect_segs: Maximum amount

Re: [PATCH v1] xen-blkfront: dynamic configuration of per-vbd resources

On Mon, Apr 02, 2018 at 01:42:32PM -0400, Konrad Rzeszutek Wilk wrote: > From: Bob Liu > > The current VBD layer reserves buffer space for each attached device based on > three statically configured settings which are read at boot time. > * max_indirect_segs: Maximum amount of segments. > *

[PATCH] xen/pirq: fix error path cleanup when binding MSIs

and unbound IRQs when freeing them, __unbind_from_irq will deal with both of them correctly. Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups") Reported-by: Hooman Mirhadi <mirha...@amazon.com> Signed-off-by: Roger Pau Monné <roger@citrix.com> --- Cc: Boris O

[PATCH] xen/pirq: fix error path cleanup when binding MSIs

and unbound IRQs when freeing them, __unbind_from_irq will deal with both of them correctly. Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups") Reported-by: Hooman Mirhadi Signed-off-by: Roger Pau Monné --- Cc: Boris Ostrovsky Cc: Juergen Gross Cc: Amit Sha

Re: [PATCH v2 2/2] xen: events: free irqs in error condition

On Tue, Feb 27, 2018 at 05:32:53PM +, Shah, Amit wrote: > > On Di, 2018-02-27 at 17:07 +, Roger Pau Monné wrote: > > On Tue, Feb 27, 2018 at 03:55:58PM +, Amit Shah wrote: > > > > > > In case of errors in irq setup for MSI, free up the allo

Re: [PATCH v2 2/2] xen: events: free irqs in error condition

On Tue, Feb 27, 2018 at 05:32:53PM +, Shah, Amit wrote: > > On Di, 2018-02-27 at 17:07 +, Roger Pau Monné wrote: > > On Tue, Feb 27, 2018 at 03:55:58PM +, Amit Shah wrote: > > > > > > In case of errors in irq setup for MSI, free up the allo

Re: [PATCH v2 2/2] xen: events: free irqs in error condition

On Tue, Feb 27, 2018 at 03:55:58PM +, Amit Shah wrote: > In case of errors in irq setup for MSI, free up the allocated irqs. > > Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups") > Reported-by: Hooman Mirhadi <mirha...@amazon.com> > CC: <sta..

Re: [PATCH v2 2/2] xen: events: free irqs in error condition

On Tue, Feb 27, 2018 at 03:55:58PM +, Amit Shah wrote: > In case of errors in irq setup for MSI, free up the allocated irqs. > > Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups") > Reported-by: Hooman Mirhadi > CC: > CC: Roger Pau Monné > CC:

Re: [PATCH v2 1/2] xen: fix out-of-bounds irq unbind for MSI message groups

m> > CC: <sta...@vger.kernel.org> > CC: Roger Pau Monné <roger@citrix.com> > CC: Boris Ostrovsky <boris.ostrov...@oracle.com> > CC: Eduardo Valentin <edu...@amazon.com> > CC: Juergen Gross <jgr...@suse.com> > CC: Thomas Gleixner <t...@linut

Re: [PATCH v2 1/2] xen: fix out-of-bounds irq unbind for MSI message groups

o I think the "potentially unbinding an unrelated irq" part is wrong. The unbind call would be performed against an unbound IRQ, which is harmless AFAICT. > Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups") > Reported-by: Hooman Mirhadi > CC: > C

Re: [PATCH 2/2] xen: events: free irqs in error condition

On Mon, Feb 26, 2018 at 06:57:03PM +, Shah, Amit wrote: > > On Mo, 2018-02-26 at 18:14 +, Roger Pau Monné wrote: > > On Mon, Feb 26, 2018 at 05:36:35PM +, Amit Shah wrote: > > > > > > In case of errors in irq setup for MSI, free up the allo

Re: [PATCH 2/2] xen: events: free irqs in error condition

On Mon, Feb 26, 2018 at 06:57:03PM +, Shah, Amit wrote: > > On Mo, 2018-02-26 at 18:14 +, Roger Pau Monné wrote: > > On Mon, Feb 26, 2018 at 05:36:35PM +, Amit Shah wrote: > > > > > > In case of errors in irq setup for MSI, free up the allo

Re: [PATCH 2/2] xen: events: free irqs in error condition

On Mon, Feb 26, 2018 at 05:36:35PM +, Amit Shah wrote: > In case of errors in irq setup for MSI, free up the allocated irqs. > > Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups") > Reported-by: Hooman Mirhadi <mirha...@amazon.com> > CC: <sta..

Re: [PATCH 2/2] xen: events: free irqs in error condition

On Mon, Feb 26, 2018 at 05:36:35PM +, Amit Shah wrote: > In case of errors in irq setup for MSI, free up the allocated irqs. > > Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups") > Reported-by: Hooman Mirhadi > CC: > CC: Roger Pau Monné >

Re: [Xen-devel] [RFC PATCH v2 2/9] hyper_dmabuf: architecture specification and reference guide

On Tue, Feb 13, 2018 at 05:50:01PM -0800, Dongwon Kim wrote: > Reference document for hyper_DMABUF driver > > Documentation/hyper-dmabuf-sharing.txt This should likely be patch 1 in order for reviewers to have the appropriate context. > > Signed-off-by: Dongwon Kim >

Re: [Xen-devel] [RFC PATCH v2 2/9] hyper_dmabuf: architecture specification and reference guide

On Tue, Feb 13, 2018 at 05:50:01PM -0800, Dongwon Kim wrote: > Reference document for hyper_DMABUF driver > > Documentation/hyper-dmabuf-sharing.txt This should likely be patch 1 in order for reviewers to have the appropriate context. > > Signed-off-by: Dongwon Kim > --- >

Re: [Xen-devel] [PATCH 1/9] drm/xen-front: Introduce Xen para-virtualized frontend driver

On Wed, Feb 21, 2018 at 11:42:23AM +0200, Oleksandr Andrushchenko wrote: > On 02/21/2018 11:17 AM, Roger Pau Monné wrote: > > On Wed, Feb 21, 2018 at 10:03:34AM +0200, Oleksandr Andrushchenko wrote: > > > --- /dev/null > > > +++ b/drivers/gpu/drm/xen/xen_drm_

Re: [Xen-devel] [PATCH 1/9] drm/xen-front: Introduce Xen para-virtualized frontend driver

On Wed, Feb 21, 2018 at 11:42:23AM +0200, Oleksandr Andrushchenko wrote: > On 02/21/2018 11:17 AM, Roger Pau Monné wrote: > > On Wed, Feb 21, 2018 at 10:03:34AM +0200, Oleksandr Andrushchenko wrote: > > > --- /dev/null > > > +++ b/drivers/gpu/drm/xen/xen_drm_

Re: [Xen-devel] [PATCH 1/9] drm/xen-front: Introduce Xen para-virtualized frontend driver

On Wed, Feb 21, 2018 at 10:03:34AM +0200, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Introduce skeleton of the para-virtualized Xen display > frontend driver. This patch only adds required > essential stubs. > > Signed-off-by: Oleksandr

Re: [Xen-devel] [PATCH 1/9] drm/xen-front: Introduce Xen para-virtualized frontend driver

On Wed, Feb 21, 2018 at 10:03:34AM +0200, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Introduce skeleton of the para-virtualized Xen display > frontend driver. This patch only adds required > essential stubs. > > Signed-off-by: Oleksandr Andrushchenko > --- >

Re: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point

On Wed, Nov 29, 2017 at 03:11:12PM +0100, Juergen Gross wrote: > On 29/11/17 15:03, Boris Ostrovsky wrote: > > On 11/29/2017 03:50 AM, Roger Pau Monné wrote: > >> On Wed, Nov 29, 2017 at 09:21:59AM +0100, Juergen Gross wrote: > >>> On 28/11/17 20:34, Maran Wi

Re: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point

On Wed, Nov 29, 2017 at 03:11:12PM +0100, Juergen Gross wrote: > On 29/11/17 15:03, Boris Ostrovsky wrote: > > On 11/29/2017 03:50 AM, Roger Pau Monné wrote: > >> On Wed, Nov 29, 2017 at 09:21:59AM +0100, Juergen Gross wrote: > >>> On 28/11/17 20:34, Maran Wi

Re: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point

On Wed, Nov 29, 2017 at 09:21:59AM +0100, Juergen Gross wrote: > On 28/11/17 20:34, Maran Wilson wrote: > > For certain applications it is desirable to rapidly boot a KVM virtual > > machine. In cases where legacy hardware and software support within the > > guest is not needed, Qemu should be

Re: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point

On Wed, Nov 29, 2017 at 09:21:59AM +0100, Juergen Gross wrote: > On 28/11/17 20:34, Maran Wilson wrote: > > For certain applications it is desirable to rapidly boot a KVM virtual > > machine. In cases where legacy hardware and software support within the > > guest is not needed, Qemu should be

Re: [Xen-devel] [PATCH 2/3] x86/acpi: take rsdp address for boot params if available

On Tue, Nov 28, 2017 at 11:30:15AM +0100, Juergen Gross wrote: > On 28/11/17 11:18, Roger Pau Monné wrote: > > On Tue, Nov 28, 2017 at 10:43:59AM +0100, Juergen Gross wrote: > >> In case the rsdp address in struct boot_params is specified don't try > >> to find the t

Re: [Xen-devel] [PATCH 2/3] x86/acpi: take rsdp address for boot params if available

On Tue, Nov 28, 2017 at 11:30:15AM +0100, Juergen Gross wrote: > On 28/11/17 11:18, Roger Pau Monné wrote: > > On Tue, Nov 28, 2017 at 10:43:59AM +0100, Juergen Gross wrote: > >> In case the rsdp address in struct boot_params is specified don't try > >> to find the t

Re: [Xen-devel] [PATCH 2/3] x86/acpi: take rsdp address for boot params if available

On Tue, Nov 28, 2017 at 10:43:59AM +0100, Juergen Gross wrote: > In case the rsdp address in struct boot_params is specified don't try > to find the table by searching, but take the address directly as set > by the boot loader. > > Signed-off-by: Juergen Gross > --- >

Re: [Xen-devel] [PATCH 2/3] x86/acpi: take rsdp address for boot params if available

On Tue, Nov 28, 2017 at 10:43:59AM +0100, Juergen Gross wrote: > In case the rsdp address in struct boot_params is specified don't try > to find the table by searching, but take the address directly as set > by the boot loader. > > Signed-off-by: Juergen Gross > --- > drivers/acpi/osl.c | 8

Re: [Xen-devel] [PATCH 3/3] x86/xen: supply rsdp address in boot params for pvh guests

On Tue, Nov 28, 2017 at 10:44:00AM +0100, Juergen Gross wrote: > When booted via the special PVH entry save the RSDP address set in the > boot information block in struct boot_params. This will enable Xen to > locate the RSDP at an arbitrary address. > > Signed-off-by: Juergen Gross

Re: [Xen-devel] [PATCH 3/3] x86/xen: supply rsdp address in boot params for pvh guests

On Tue, Nov 28, 2017 at 10:44:00AM +0100, Juergen Gross wrote: > When booted via the special PVH entry save the RSDP address set in the > boot information block in struct boot_params. This will enable Xen to > locate the RSDP at an arbitrary address. > > Signed-off-by: Juergen Gross > --- >

Re: [Xen-devel] [PATCH 1/3] x86/boot: add acpi rsdp address to setup_header

> kernel. > > For this purpose expand the struct setup_header to hold the physical > address of the RSDP address. Being zero means it isn't specified and > has to be located the legacy way (searching through low memory or > EBDA). > > Signed-off-by: Juergen Gross <jgr...@suse.com&g

<    1   2   3   4   5   6   7   8   9   10   >