All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	"Dong, Eddie" <eddie.dong@intel.com>,
	Jan Beulich <jbeulich@suse.com>,
	Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [PATCH RFC] xen/pvh: use a custom IO bitmap for PVH hardware domains
Date: Fri, 10 Apr 2015 13:07:12 +0200	[thread overview]
Message-ID: <5527AEE0.5030905@citrix.com> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D126206157@SHSMSX101.ccr.corp.intel.com>

El 10/04/15 a les 3.43, Tian, Kevin ha escrit:
>> From: Roger Pau Monne [mailto:roger.pau@citrix.com]
[...]
>> diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
>> index e5c845c..d0365fe 100644
>> --- a/xen/arch/x86/domain_build.c
>> +++ b/xen/arch/x86/domain_build.c
>> @@ -22,6 +22,7 @@
>>  #include <xen/compat.h>
>>  #include <xen/libelf.h>
>>  #include <xen/pfn.h>
>> +#include <xen/serial.h>
>>  #include <asm/regs.h>
>>  #include <asm/system.h>
>>  #include <asm/io.h>
>> @@ -1541,6 +1542,11 @@ int __init construct_dom0(
>>      rc |= ioports_deny_access(d, 0x40, 0x43);
>>      /* PIT Channel 2 / PC Speaker Control. */
>>      rc |= ioports_deny_access(d, 0x61, 0x61);
>> +    /* Serial console. */
>> +    if ( uart_ioport1 != 0 )
>> +        rc |= ioports_deny_access(d, uart_ioport1, uart_ioport1 + 7);
>> +    if ( uart_ioport2 != 0 )
>> +        rc |= ioports_deny_access(d, uart_ioport2, uart_ioport2 + 7);
> 
> would this be better in actual serial driver?

Definitely, I'm doing it this way because at the point were the uart is
set the initial domain struct has not even been created, much less
passed to the uart driver code.

I will rework this to be more similar to mmio_ro_ranges, which can be
set from driver code directly.

[...]

>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -82,6 +82,10 @@ struct hvm_function_table hvm_funcs __read_mostly;
>>  unsigned long __attribute__ ((__section__ (".bss.page_aligned")))
>>      hvm_io_bitmap[3*PAGE_SIZE/BYTES_PER_LONG];
>>
>> +/* I/O permission bitmap for HVM hardware domain */
>> +unsigned long __attribute__ ((__section__ (".bss.page_aligned")))
>> +    hvm_hw_io_bitmap[3*PAGE_SIZE/BYTES_PER_LONG];
>> +
>>  /* Xen command-line option to enable HAP */
>>  static bool_t __initdata opt_hap_enabled = 1;
>>  boolean_param("hap", opt_hap_enabled);
>> @@ -162,6 +166,7 @@ static int __init hvm_enable(void)
>>       * often used for I/O delays, but the vmexits simply slow things down).
>>       */
>>      memset(hvm_io_bitmap, ~0, sizeof(hvm_io_bitmap));
>> +    memset(hvm_hw_io_bitmap, ~0, sizeof(hvm_hw_io_bitmap));
>>      if ( hvm_port80_allowed )
>>          __clear_bit(0x80, hvm_io_bitmap);
>>      __clear_bit(0xed, hvm_io_bitmap);
>> @@ -1484,6 +1489,12 @@ int hvm_domain_initialise(struct domain *d)
>>          goto fail1;
>>      d->arch.hvm_domain.io_handler->num_slot = 0;
>>
>> +    /* Set the default IO Bitmap */
>> +    if ( is_hardware_domain(d) )
>> +        d->arch.hvm_domain.io_bitmap = hvm_hw_io_bitmap;
>> +    else
>> +        d->arch.hvm_domain.io_bitmap = hvm_io_bitmap;
>> +
> 
> if we want to support multiple PVH hardware domains w/ different
> permissions, using global array is not correct here.

Isn't there supposed to be only one hardware domain that has access to
the full hardware?

Roger.

  reply	other threads:[~2015-04-10 11:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-08 12:57 [PATCH RFC] xen/pvh: use a custom IO bitmap for PVH hardware domains Roger Pau Monne
2015-04-09 10:55 ` Andrew Cooper
2015-04-14  8:11   ` Jan Beulich
2015-04-10  1:43 ` Tian, Kevin
2015-04-10 11:07   ` Roger Pau Monné [this message]
2015-04-14  7:57   ` Jan Beulich
2015-04-14  8:06 ` Jan Beulich
2015-04-14 10:01 ` Roger Pau Monné
2015-04-14 10:05   ` Andrew Cooper
2015-04-14 10:31   ` Jan Beulich
2015-04-14 10:45     ` Roger Pau Monné
2015-04-14 11:40       ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5527AEE0.5030905@citrix.com \
    --to=roger.pau@citrix.com \
    --cc=Aravind.Gopalakrishnan@amd.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=eddie.dong@intel.com \
    --cc=jbeulich@suse.com \
    --cc=jun.nakajima@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.