xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
* [PATCH RFC] x86/HVM: assume default ioreq servers follow new bufioreq pointer access model
@ 2015-08-28 16:15 Jan Beulich
  2015-08-28 16:20 ` Andrew Cooper
  0 siblings, 1 reply; 4+ messages in thread
From: Jan Beulich @ 2015-08-28 16:15 UTC (permalink / raw)
  To: xen-devel; +Cc: Andrew Cooper, Keir Fraser, Ian Jackson, Stefano Stabellini

[-- Attachment #1: Type: text/plain, Size: 640 bytes --]

There's no way for Xen to know or for such a qemu to tell us.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
RFC: This implies only patched qemu-trad or ioreq-server-aware
     qemu-upstream get used with xen-unstable. Is this reasonable?

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1040,7 +1040,7 @@ static int hvm_ioreq_server_init(struct 
     if ( rc )
         return rc;
 
-    if ( bufioreq_handling == HVM_IOREQSRV_BUFIOREQ_ATOMIC )
+    if ( bufioreq_handling == HVM_IOREQSRV_BUFIOREQ_ATOMIC || is_default )
         s->bufioreq_atomic = 1;
 
     rc = hvm_ioreq_server_setup_pages(




[-- Attachment #2: x86-HVM-bufioreq-default-atomic.patch --]
[-- Type: text/plain, Size: 716 bytes --]

x86/HVM: assume default ioreq servers follow new bufioreq pointer access model

There's no way for Xen to know or for such a qemu to tell us.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
RFC: This implies only patched qemu-trad or ioreq-server-aware
     qemu-upstream get used with xen-unstable. Is this reasonable?

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1040,7 +1040,7 @@ static int hvm_ioreq_server_init(struct 
     if ( rc )
         return rc;
 
-    if ( bufioreq_handling == HVM_IOREQSRV_BUFIOREQ_ATOMIC )
+    if ( bufioreq_handling == HVM_IOREQSRV_BUFIOREQ_ATOMIC || is_default )
         s->bufioreq_atomic = 1;
 
     rc = hvm_ioreq_server_setup_pages(

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH RFC] x86/HVM: assume default ioreq servers follow new bufioreq pointer access model
  2015-08-28 16:15 [PATCH RFC] x86/HVM: assume default ioreq servers follow new bufioreq pointer access model Jan Beulich
@ 2015-08-28 16:20 ` Andrew Cooper
  2015-09-01 13:15   ` Stefano Stabellini
  0 siblings, 1 reply; 4+ messages in thread
From: Andrew Cooper @ 2015-08-28 16:20 UTC (permalink / raw)
  To: Jan Beulich, xen-devel; +Cc: Ian Jackson, Keir Fraser, Stefano Stabellini

On 28/08/15 17:15, Jan Beulich wrote:
> There's no way for Xen to know or for such a qemu to tell us.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> RFC: This implies only patched qemu-trad or ioreq-server-aware
>      qemu-upstream get used with xen-unstable. Is this reasonable?

Patched qemu-trad, yes, as it comes from the same source.

Much less certain about qemu-upstream.  There is deliberate support to
use a distro provided qemu-upstream as opposed to a xen provided one.

~Andrew

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH RFC] x86/HVM: assume default ioreq servers follow new bufioreq pointer access model
  2015-08-28 16:20 ` Andrew Cooper
@ 2015-09-01 13:15   ` Stefano Stabellini
  2015-09-01 13:48     ` Jan Beulich
  0 siblings, 1 reply; 4+ messages in thread
From: Stefano Stabellini @ 2015-09-01 13:15 UTC (permalink / raw)
  To: Andrew Cooper
  Cc: xen-devel, Keir Fraser, Ian Jackson, Jan Beulich,
	Stefano Stabellini

On Fri, 28 Aug 2015, Andrew Cooper wrote:
> On 28/08/15 17:15, Jan Beulich wrote:
> > There's no way for Xen to know or for such a qemu to tell us.
> >
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > ---
> > RFC: This implies only patched qemu-trad or ioreq-server-aware
> >      qemu-upstream get used with xen-unstable. Is this reasonable?
> 
> Patched qemu-trad, yes, as it comes from the same source.
> 
> Much less certain about qemu-upstream.  There is deliberate support to
> use a distro provided qemu-upstream as opposed to a xen provided one.
 
That's right. Distros are free to mix and match upstream QEMU and Xen
versions.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH RFC] x86/HVM: assume default ioreq servers follow new bufioreq pointer access model
  2015-09-01 13:15   ` Stefano Stabellini
@ 2015-09-01 13:48     ` Jan Beulich
  0 siblings, 0 replies; 4+ messages in thread
From: Jan Beulich @ 2015-09-01 13:48 UTC (permalink / raw)
  To: Andrew Cooper, Stefano Stabellini; +Cc: xen-devel, Keir Fraser, Ian Jackson

>>> On 01.09.15 at 15:15, <stefano.stabellini@eu.citrix.com> wrote:
> On Fri, 28 Aug 2015, Andrew Cooper wrote:
>> On 28/08/15 17:15, Jan Beulich wrote:
>> > There's no way for Xen to know or for such a qemu to tell us.
>> >
>> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> > ---
>> > RFC: This implies only patched qemu-trad or ioreq-server-aware
>> >      qemu-upstream get used with xen-unstable. Is this reasonable?
>> 
>> Patched qemu-trad, yes, as it comes from the same source.
>> 
>> Much less certain about qemu-upstream.  There is deliberate support to
>> use a distro provided qemu-upstream as opposed to a xen provided one.
>  
> That's right. Distros are free to mix and match upstream QEMU and Xen
> versions.

Sigh. So to avoid adding an interface just for qemu-trad to use -
is there a way to reliably tell a non-ioreq-server-aware upstream
qemu from qemu-trad inside the hypervisor?

Jan

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-09-01 13:48 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-08-28 16:15 [PATCH RFC] x86/HVM: assume default ioreq servers follow new bufioreq pointer access model Jan Beulich
2015-08-28 16:20 ` Andrew Cooper
2015-09-01 13:15   ` Stefano Stabellini
2015-09-01 13:48     ` Jan Beulich

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).