From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [v7][RFC][PATCH 06/13] hvmloader/ram: check if guest memory is out of reserved device memory maps Date: Tue, 11 Nov 2014 17:35:00 +0800 Message-ID: <5461D844.7090702@intel.com> References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com> <5451AC56.7010303@intel.com> <54521100020000780004363A@mail.emea.novell.com> <545320F2.5030103@intel.com> <545354500200007800043D94@mail.emea.novell.com> <5457174C.8020400@intel.com> <5457515102000078000443B0@mail.emea.novell.com> <54574D8F.8060407@intel.com> <54575E2D0200007800044443@mail.emea.novell.com> <545767C4.7070806@intel.com> <5457787002000078000445C7@mail.emea.novell.com> <54576DF7.8060408@intel.com> <545784830200007800044627@mail.emea.novell.com> <54585EAA.20904@intel.com> <545894610200007800044A5B@mail.emea.novell.com> <545992A2.8070309@intel.com> <545A57AD02000078000C1037@mail.emea.novell.com> <545B3F4A.5070808@intel.com> <545B562F02000078000453FB@mail.emea.novell.com> <545C9E97.4040800@intel.com> <545CB64E02000078000459CD@mail.emea.novell.com> <5461AD94.2070008@intel.com> <5461DDFB020000780004650C@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5461DDFB020000780004650C@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org >> Do you mean this line? >> >> copy_from_guest_offset(pcidevs, xdsr->pcidevs, 0, >> xdsr->num_pcidevs*sizeof(xen_guest_pcidev_info_t)) > > Almost: > > copy_from_guest(pcidevs, xdsr->pcidevs, xdsr->num_pcidevs * sizeof(*pcidevs)) Fixed. > >>>> --- a/xen/include/asm-x86/hvm/domain.h >>>> +++ b/xen/include/asm-x86/hvm/domain.h >>>> @@ -90,6 +90,10 @@ struct hvm_domain { >>>> /* Cached CF8 for guest PCI config cycles */ >>>> uint32_t pci_cf8; >>>> >>>> + uint32_t pci_rdmforce; >>> >>> I still don't see why this is a uint32_t. >> >> How about bool_t? > > Exactly. > >> In Xen side we have 'bool_t', but we have 'bool' in tools side. So how >> to define this in xen/include/public/domctl.h? > > Have a structure field named e.g. "flags" and a #define consuming > exactly one bit of it. Just like it's being done everywhere else. Like this? typedef struct xen_domctl_assign_device xen_domctl_assign_device_t; DEFINE_XEN_GUEST_HANDLE(xen_domctl_assign_device_t); +struct xen_guest_pcidev_info { + uint8_t bus; + uint8_t devfn; + struct { + uint32_t force : 1, + reserved : 31; + }flags; +}; +typedef struct xen_guest_pcidev_info xen_guest_pcidev_info_t; +DEFINE_XEN_GUEST_HANDLE(xen_guest_pcidev_info_t); +/* Control whether/how we check and reserve device memory. */ +struct xen_domctl_set_rdm { + struct { + uint32_t force : 1, + reserved : 31; + }flags; + uint32_t num_pcidevs; + XEN_GUEST_HANDLE_64(xen_guest_pcidev_info_t) pcidevs; +}; +typedef struct xen_domctl_set_rdm xen_domctl_set_rdm_t; +DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_rdm_t); + /* Retrieve sibling devices infomation of machine_sbdf */ /* XEN_DOMCTL_get_device_group */ struct xen_domctl_get_device_group { > >>>> @@ -1118,7 +1137,8 @@ struct xen_domctl { >>>> struct xen_domctl_gdbsx_domstatus gdbsx_domstatus; >>>> struct xen_domctl_vnuma vnuma; >>>> struct xen_domctl_psr_cmt_op psr_cmt_op; >>>> - uint8_t pad[128]; >>>> + struct xen_domctl_set_rdm set_rdm; >>>> + uint8_t pad[112]; >>> >>> Why are you altering the padding size here? >> >> As I understand we should shrink this pad when we introduce new filed, >> shouldn't we? > > You realize that this is inside a union? Sorry I didn't realize this point. Thanks Tiejun