All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Chen, Tiejun" <tiejun.chen@intel.com>
To: "Tian, Kevin" <kevin.tian@intel.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"tim@xen.org" <tim@xen.org>,
	"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"Ian.Jackson@eu.citrix.com" <Ian.Jackson@eu.citrix.com>,
	"stefano.stabellini@citrix.com" <stefano.stabellini@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [v3][PATCH 04/16] xen/passthrough: extend hypercall to support rdm reservation policy
Date: Fri, 12 Jun 2015 14:31:03 +0800	[thread overview]
Message-ID: <557A7CA7.9000305@intel.com> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D12628A06E@SHSMSX101.ccr.corp.intel.com>

On 2015/6/11 17:28, Tian, Kevin wrote:
>> From: Chen, Tiejun
>> Sent: Thursday, June 11, 2015 9:15 AM
>>
>> This patch extends the existing hypercall to support rdm reservation policy.
>> We return error or just throw out a warning message depending on whether
>> the policy is "strict" or "relaxed" when reserving RDM regions in pfn space.
>> Note in some special cases, e.g. add a device to hwdomain, and remove a
>> device from user domain, 'relaxed' is fine enough since this is always safe
>> to hwdomain.
>
> could you elaborate " add a device to hwdomain, and remove a device
> from user domain "? move a device from user domain to hwdomain
> or completely irrelevant?

Yes, they're not relevant. And I think we shouldn't care our policy,

#1. When add a device to hwdomain

I think RMRR is always reserved on e820 so either of flag is fine.

#2. remove a device from domain

"remove" action also can ignore that since the original mechanism is 
enough.

>
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> ---
>>   xen/arch/x86/mm/p2m.c                       |  8 +++++++-
>>   xen/drivers/passthrough/amd/pci_amd_iommu.c |  3 ++-
>>   xen/drivers/passthrough/arm/smmu.c          |  2 +-
>>   xen/drivers/passthrough/device_tree.c       | 11 ++++++++++-
>>   xen/drivers/passthrough/pci.c               | 10 ++++++----
>>   xen/drivers/passthrough/vtd/iommu.c         | 20 ++++++++++++--------
>>   xen/include/asm-x86/p2m.h                   |  2 +-
>>   xen/include/public/domctl.h                 |  5 +++++
>>   xen/include/xen/iommu.h                     |  2 +-
>>   9 files changed, 45 insertions(+), 18 deletions(-)
>>
>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
>> index c7198a5..3fcdcac 100644
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -899,7 +899,7 @@ int set_mmio_p2m_entry(struct domain *d, unsigned long gfn,
>> mfn_t mfn,
>>   }
>>
>>   int set_identity_p2m_entry(struct domain *d, unsigned long gfn,
>> -                           p2m_access_t p2ma)
>> +                           p2m_access_t p2ma, u32 flag)
>>   {
>>       p2m_type_t p2mt;
>>       p2m_access_t a;
>> @@ -924,6 +924,12 @@ int set_identity_p2m_entry(struct domain *d, unsigned long gfn,
>>               printk(XENLOG_G_WARNING
>>                      "Cannot identity map d%d:%lx, already mapped to %lx.\n",
>>                      d->domain_id, gfn, mfn_x(mfn));
>> +
>> +            if ( flag == XEN_DOMCTL_DEV_RDM_RELAXED )
>> +            {
>> +                ret = 0;
>> +                printk(XENLOG_G_WARNING "Some devices may work failed.\n");
>
> Do you need this extra printk? The warning message is already given
> several lines above and here you just need to change return value
> for relaxed policy.

Okay.

>
>> +            }
>>           }
>>
>>           gfn_unlock(p2m, gfn, 0);
>> diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> b/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> index e83bb35..920b35a 100644
>> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> @@ -394,7 +394,8 @@ static int reassign_device(struct domain *source, struct domain
>> *target,
>>   }
>>
>>   static int amd_iommu_assign_device(struct domain *d, u8 devfn,
>> -                                   struct pci_dev *pdev)
>> +                                   struct pci_dev *pdev,
>> +                                   u32 flag)
>>   {
>>       struct ivrs_mappings *ivrs_mappings = get_ivrs_mappings(pdev->seg);
>>       int bdf = PCI_BDF2(pdev->bus, devfn);
>> diff --git a/xen/drivers/passthrough/arm/smmu.c
>> b/xen/drivers/passthrough/arm/smmu.c
>> index 6cc4394..9a667e9 100644
>> --- a/xen/drivers/passthrough/arm/smmu.c
>> +++ b/xen/drivers/passthrough/arm/smmu.c
>> @@ -2605,7 +2605,7 @@ static void arm_smmu_destroy_iommu_domain(struct
>> iommu_domain *domain)
>>   }
>>
>>   static int arm_smmu_assign_dev(struct domain *d, u8 devfn,
>> -			       struct device *dev)
>> +			       struct device *dev, u32 flag)
>>   {
>>   	struct iommu_domain *domain;
>>   	struct arm_smmu_xen_domain *xen_domain;
>> diff --git a/xen/drivers/passthrough/device_tree.c
>> b/xen/drivers/passthrough/device_tree.c
>> index 5d3842a..ea85645 100644
>> --- a/xen/drivers/passthrough/device_tree.c
>> +++ b/xen/drivers/passthrough/device_tree.c
>> @@ -52,7 +52,8 @@ int iommu_assign_dt_device(struct domain *d, struct
>> dt_device_node *dev)
>>               goto fail;
>>       }
>>
>> -    rc = hd->platform_ops->assign_device(d, 0, dt_to_dev(dev));
>> +    rc = hd->platform_ops->assign_device(d, 0, dt_to_dev(dev),
>> +                                         XEN_DOMCTL_DEV_NO_RDM);
>>
>>       if ( rc )
>>           goto fail;
>> @@ -148,6 +149,14 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct
>> domain *d,
>>           if ( domctl->u.assign_device.dev != XEN_DOMCTL_DEV_DT )
>>               break;
>>
>> +        if ( domctl->u.assign_device.flag == XEN_DOMCTL_DEV_NO_RDM )
>> +        {
>> +            printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: assign \"%s\""
>> +                   " to dom%u failed (%d) since we don't support RDM.\n",
>> +                   dt_node_full_name(dev), d->domain_id, ret);
>> +            break;
>> +        }
>> +
>>           if ( unlikely(d->is_dying) )
>>           {
>>               ret = -EINVAL;
>> diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
>> index e30be43..557c87e 100644
>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -1335,7 +1335,7 @@ static int device_assigned(u16 seg, u8 bus, u8 devfn)
>>       return pdev ? 0 : -EBUSY;
>>   }
>>
>> -static int assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn)
>> +static int assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn, u32 flag)
>>   {
>>       struct hvm_iommu *hd = domain_hvm_iommu(d);
>>       struct pci_dev *pdev;
>> @@ -1371,7 +1371,7 @@ static int assign_device(struct domain *d, u16 seg, u8 bus, u8
>> devfn)
>>
>>       pdev->fault.count = 0;
>>
>> -    if ( (rc = hd->platform_ops->assign_device(d, devfn, pci_to_dev(pdev))) )
>> +    if ( (rc = hd->platform_ops->assign_device(d, devfn, pci_to_dev(pdev), flag)) )
>>           goto done;
>>
>>       for ( ; pdev->phantom_stride; rc = 0 )
>> @@ -1379,7 +1379,7 @@ static int assign_device(struct domain *d, u16 seg, u8 bus, u8
>> devfn)
>>           devfn += pdev->phantom_stride;
>>           if ( PCI_SLOT(devfn) != PCI_SLOT(pdev->devfn) )
>>               break;
>> -        rc = hd->platform_ops->assign_device(d, devfn, pci_to_dev(pdev));
>> +        rc = hd->platform_ops->assign_device(d, devfn, pci_to_dev(pdev), flag);
>>           if ( rc )
>>               printk(XENLOG_G_WARNING "d%d: assign %04x:%02x:%02x.%u failed
>> (%d)\n",
>>                      d->domain_id, seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
>> @@ -1496,6 +1496,7 @@ int iommu_do_pci_domctl(
>>   {
>>       u16 seg;
>>       u8 bus, devfn;
>> +    u32 flag;
>>       int ret = 0;
>>       uint32_t machine_sbdf;
>>
>> @@ -1577,9 +1578,10 @@ int iommu_do_pci_domctl(
>>           seg = machine_sbdf >> 16;
>>           bus = PCI_BUS(machine_sbdf);
>>           devfn = PCI_DEVFN2(machine_sbdf);
>> +        flag = domctl->u.assign_device.flag;
>>
>>           ret = device_assigned(seg, bus, devfn) ?:
>> -              assign_device(d, seg, bus, devfn);
>> +              assign_device(d, seg, bus, devfn, flag);
>>           if ( ret == -ERESTART )
>>               ret = hypercall_create_continuation(__HYPERVISOR_domctl,
>>                                                   "h", u_domctl);
>> diff --git a/xen/drivers/passthrough/vtd/iommu.c
>> b/xen/drivers/passthrough/vtd/iommu.c
>> index 31ce1af..d7c9e1c 100644
>> --- a/xen/drivers/passthrough/vtd/iommu.c
>> +++ b/xen/drivers/passthrough/vtd/iommu.c
>> @@ -1808,7 +1808,8 @@ static void iommu_set_pgd(struct domain *d)
>>   }
>>
>>   static int rmrr_identity_mapping(struct domain *d, bool_t map,
>> -                                 const struct acpi_rmrr_unit *rmrr)
>> +                                 const struct acpi_rmrr_unit *rmrr,
>> +                                 u32 flag)
>>   {
>>       unsigned long base_pfn = rmrr->base_address >> PAGE_SHIFT_4K;
>>       unsigned long end_pfn = PAGE_ALIGN_4K(rmrr->end_address) >>
>> PAGE_SHIFT_4K;
>> @@ -1856,7 +1857,7 @@ static int rmrr_identity_mapping(struct domain *d, bool_t map,
>>
>>       while ( base_pfn < end_pfn )
>>       {
>> -        int err = set_identity_p2m_entry(d, base_pfn, p2m_access_rw);
>> +        int err = set_identity_p2m_entry(d, base_pfn, p2m_access_rw, flag);
>>
>>           if ( err )
>>               return err;
>> @@ -1899,7 +1900,8 @@ static int intel_iommu_add_device(u8 devfn, struct pci_dev
>> *pdev)
>>                PCI_BUS(bdf) == pdev->bus &&
>>                PCI_DEVFN2(bdf) == devfn )
>>           {
>> -            ret = rmrr_identity_mapping(pdev->domain, 1, rmrr);
>> +            ret = rmrr_identity_mapping(pdev->domain, 1, rmrr,
>> +                                        XEN_DOMCTL_DEV_RDM_RELAXED);
>
> Why did you hardcode relax policy here? Shouldn't the policy come
> from hypercall flag?

I just saw we have one path to use intel_iommu_add_device(),

pci_add_device()
     |
     + if ( !pdev->domain )
       {
         pdev->domain = hardware_domain;
         ret = iommu_add_device(pdev);
	    |
	    + hd->platform_ops->add_device()
		|
		+ intel_iommu_add_device()

So I think intel_iommu_add_device() is used to add a device to 
hardware_domain. And in our case hardware_domain should be special as I 
explained above.

>
>>               if ( ret )
>>                   dprintk(XENLOG_ERR VTDPREFIX, "d%d: RMRR mapping failed\n",
>>                           pdev->domain->domain_id);
>> @@ -1940,7 +1942,8 @@ static int intel_iommu_remove_device(u8 devfn, struct pci_dev
>> *pdev)
>>                PCI_DEVFN2(bdf) != devfn )
>>               continue;
>>
>> -        rmrr_identity_mapping(pdev->domain, 0, rmrr);
>> +        rmrr_identity_mapping(pdev->domain, 0, rmrr,
>> +                              XEN_DOMCTL_DEV_RDM_RELAXED);
>
> ditto

It doesn't matter when we're trying to remove a device since we don't 
care this flag.

>
>>       }
>>
>>       return domain_context_unmap(pdev->domain, devfn, pdev);
>> @@ -2098,7 +2101,7 @@ static void __hwdom_init setup_hwdom_rmrr(struct domain *d)
>>       spin_lock(&pcidevs_lock);
>>       for_each_rmrr_device ( rmrr, bdf, i )
>>       {
>> -        ret = rmrr_identity_mapping(d, 1, rmrr);
>> +        ret = rmrr_identity_mapping(d, 1, rmrr, XEN_DOMCTL_DEV_RDM_RELAXED);
>>           if ( ret )
>>               dprintk(XENLOG_ERR VTDPREFIX,
>>                        "IOMMU: mapping reserved region failed\n");
>> @@ -2241,7 +2244,8 @@ static int reassign_device_ownership(
>>                    PCI_BUS(bdf) == pdev->bus &&
>>                    PCI_DEVFN2(bdf) == devfn )
>>               {
>> -                ret = rmrr_identity_mapping(source, 0, rmrr);
>> +                ret = rmrr_identity_mapping(source, 0, rmrr,
>> +                                            XEN_DOMCTL_DEV_RDM_RELAXED);
>>                   if ( ret != -ENOENT )
>>                       return ret;
>>               }
>> @@ -2265,7 +2269,7 @@ static int reassign_device_ownership(
>>   }
>>
>>   static int intel_iommu_assign_device(
>> -    struct domain *d, u8 devfn, struct pci_dev *pdev)
>> +    struct domain *d, u8 devfn, struct pci_dev *pdev, u32 flag)
>>   {
>>       struct acpi_rmrr_unit *rmrr;
>>       int ret = 0, i;
>> @@ -2294,7 +2298,7 @@ static int intel_iommu_assign_device(
>>                PCI_BUS(bdf) == bus &&
>>                PCI_DEVFN2(bdf) == devfn )
>>           {
>> -            ret = rmrr_identity_mapping(d, 1, rmrr);
>> +            ret = rmrr_identity_mapping(d, 1, rmrr, flag);
>>               if ( ret )
>>               {
>>                   reassign_device_ownership(d, hardware_domain, devfn, pdev);
>> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
>> index 95b6266..a80b4f8 100644
>> --- a/xen/include/asm-x86/p2m.h
>> +++ b/xen/include/asm-x86/p2m.h
>> @@ -545,7 +545,7 @@ int clear_mmio_p2m_entry(struct domain *d, unsigned long gfn,
>> mfn_t mfn);
>>
>>   /* Set identity addresses in the p2m table (for pass-through) */
>>   int set_identity_p2m_entry(struct domain *d, unsigned long gfn,
>> -                           p2m_access_t p2ma);
>> +                           p2m_access_t p2ma, u32 flag);
>>
>>   /* Add foreign mapping to the guest's p2m table. */
>>   int p2m_add_foreign(struct domain *tdom, unsigned long fgfn,
>> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
>> index bc45ea5..2f9e40e 100644
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -478,6 +478,11 @@ struct xen_domctl_assign_device {
>>               XEN_GUEST_HANDLE_64(char) path; /* path to the device tree node */
>>           } dt;
>>       } u;
>> +    /* IN */
>> +#define XEN_DOMCTL_DEV_NO_RDM           0
>> +#define XEN_DOMCTL_DEV_RDM_RELAXED      1
>> +#define XEN_DOMCTL_DEV_RDM_STRICT       2
>
> I don't understand why we require a NO_RDM flag. Whether there
> is RDM associated with a given device, it's reported by system
> BIOS or through cmdline extension in coming patch. Why do we
> require the hypercall to ask NO_RDM to hypervisor? The only flags
> we want to pass to hypervisor is relaxed/strict policy, so hypervisor
> know whether to fail or warn upon caught conflicts of identity
> mapping...
>

This is just introduced to ARM as we discussed previously since we're 
touching some common interfaces.

Thanks
Tiejun

  reply	other threads:[~2015-06-12  6:31 UTC|newest]

Thread overview: 114+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-11  1:15 [v3][PATCH 00/16] Fix RMRR Tiejun Chen
2015-06-11  1:15 ` [v3][PATCH 01/16] xen: introduce XENMEM_reserved_device_memory_map Tiejun Chen
2015-06-11  8:56   ` Tian, Kevin
2015-06-11  1:15 ` [v3][PATCH 02/16] xen/x86/p2m: introduce set_identity_p2m_entry Tiejun Chen
2015-06-11  7:33   ` Jan Beulich
2015-06-11  8:23     ` Chen, Tiejun
2015-06-11  9:23       ` Jan Beulich
2015-06-11  9:25         ` Chen, Tiejun
2015-06-11  9:00   ` Tian, Kevin
2015-06-11  9:18     ` Chen, Tiejun
2015-06-11  1:15 ` [v3][PATCH 03/16] xen/vtd: create RMRR mapping Tiejun Chen
2015-06-11  9:14   ` Tian, Kevin
2015-06-11  9:31     ` Chen, Tiejun
2015-06-11 14:07       ` Tim Deegan
2015-06-12  2:43         ` Chen, Tiejun
2015-06-12  5:58           ` Chen, Tiejun
2015-06-12  5:59             ` Tian, Kevin
2015-06-12  6:13               ` Chen, Tiejun
2015-06-18 10:07                 ` Tim Deegan
2015-06-19  0:37                   ` Chen, Tiejun
2015-06-17 10:03   ` Jan Beulich
2015-06-18  6:23     ` Chen, Tiejun
2015-06-11  1:15 ` [v3][PATCH 04/16] xen/passthrough: extend hypercall to support rdm reservation policy Tiejun Chen
2015-06-11  9:28   ` Tian, Kevin
2015-06-12  6:31     ` Chen, Tiejun [this message]
2015-06-12  8:45       ` Jan Beulich
2015-06-12  9:20         ` Chen, Tiejun
2015-06-12  9:26           ` Jan Beulich
2015-06-15  7:39           ` Chen, Tiejun
2015-06-16  2:30       ` Tian, Kevin
2015-06-17 10:11   ` Jan Beulich
2015-06-18  7:14     ` Chen, Tiejun
2015-06-18  7:53       ` Jan Beulich
2015-06-18  8:48         ` Chen, Tiejun
2015-06-18  9:13           ` Jan Beulich
2015-06-18  9:31             ` Chen, Tiejun
2015-06-11  1:15 ` [v3][PATCH 05/16] xen: enable XENMEM_memory_map in hvm Tiejun Chen
2015-06-11  9:29   ` Tian, Kevin
2015-06-17 10:14   ` Jan Beulich
2015-06-18  8:53     ` Chen, Tiejun
2015-06-11  1:15 ` [v3][PATCH 06/16] hvmloader: get guest memory map into memory_map[] Tiejun Chen
2015-06-11  9:38   ` Tian, Kevin
2015-06-12  7:33     ` Chen, Tiejun
2015-06-17 10:22   ` Jan Beulich
2015-06-18  9:13     ` Chen, Tiejun
2015-06-11  1:15 ` [v3][PATCH 07/16] hvmloader/pci: skip reserved ranges Tiejun Chen
2015-06-11  9:51   ` Tian, Kevin
2015-06-12  7:53     ` Chen, Tiejun
2015-06-16  5:47       ` Tian, Kevin
2015-06-16  9:29         ` Chen, Tiejun
2015-06-16  9:40           ` Jan Beulich
2015-06-17  7:10             ` Chen, Tiejun
2015-06-17  7:19               ` Jan Beulich
2015-06-17  7:54                 ` Chen, Tiejun
2015-06-17  8:05                   ` Jan Beulich
2015-06-17  8:26                     ` Chen, Tiejun
2015-06-17  8:47                       ` Chen, Tiejun
2015-06-17  9:02                       ` Jan Beulich
2015-06-17  9:18                         ` Chen, Tiejun
2015-06-17  9:24                           ` Jan Beulich
2015-06-18  6:17                             ` Chen, Tiejun
2015-06-18  6:29                               ` Jan Beulich
2015-06-18  7:01                                 ` Chen, Tiejun
2015-06-18  8:05                                   ` Jan Beulich
2015-06-19  2:02                                     ` Chen, Tiejun
2015-06-23  9:46                                       ` Chen, Tiejun
2015-06-11  1:15 ` [v3][PATCH 08/16] hvmloader/e820: construct guest e820 table Tiejun Chen
2015-06-11  9:59   ` Tian, Kevin
2015-06-12  8:19     ` Chen, Tiejun
2015-06-16  5:54       ` Tian, Kevin
2015-06-11  1:15 ` [v3][PATCH 09/16] tools/libxc: Expose new hypercall xc_reserved_device_memory_map Tiejun Chen
2015-06-11 10:00   ` Tian, Kevin
2015-06-11  1:15 ` [v3][PATCH 10/16] tools: extend xc_assign_device() to support rdm reservation policy Tiejun Chen
2015-06-11 10:02   ` Tian, Kevin
2015-06-12  8:25     ` Chen, Tiejun
2015-06-16  2:28       ` Tian, Kevin
2015-06-12 15:43   ` Wei Liu
2015-06-15  1:12     ` Chen, Tiejun
2015-06-15 14:58       ` Wei Liu
2015-06-16  2:31         ` Chen, Tiejun
2015-06-11  1:15 ` [v3][PATCH 11/16] tools: introduce some new parameters to set rdm policy Tiejun Chen
2015-06-12 16:02   ` Wei Liu
2015-06-15  1:19     ` Chen, Tiejun
2015-06-11  1:15 ` [v3][PATCH 12/16] tools/libxl: passes rdm reservation policy Tiejun Chen
2015-06-12 16:17   ` Wei Liu
2015-06-15  1:26     ` Chen, Tiejun
2015-06-15 15:00       ` Wei Liu
2015-06-11  1:15 ` [v3][PATCH 13/16] tools/libxl: detect and avoid conflicts with RDM Tiejun Chen
2015-06-11 10:19   ` Tian, Kevin
2015-06-12  8:30     ` Chen, Tiejun
2015-06-12 16:39   ` Wei Liu
2015-06-15  1:50     ` Chen, Tiejun
2015-06-15 15:01       ` Wei Liu
2015-06-16  1:44         ` Chen, Tiejun
2015-06-11  1:15 ` [v3][PATCH 14/16] tools/libxl: extend XENMEM_set_memory_map Tiejun Chen
2015-06-12 16:43   ` Wei Liu
2015-06-15  2:15     ` Chen, Tiejun
2015-06-11  1:15 ` [v3][PATCH 15/16] xen/vtd: enable USB device assignment Tiejun Chen
2015-06-11 10:22   ` Tian, Kevin
2015-06-12  8:59     ` Chen, Tiejun
2015-06-16  5:58       ` Tian, Kevin
2015-06-16  6:09         ` Chen, Tiejun
2015-06-11  1:15 ` [v3][PATCH 16/16] xen/vtd: prevent from assign the device with shared rmrr Tiejun Chen
2015-06-11 10:25   ` Tian, Kevin
2015-06-12  8:44     ` Chen, Tiejun
2015-06-17 10:28   ` Jan Beulich
2015-06-18  9:23     ` Chen, Tiejun
2015-06-11  7:27 ` [v3][PATCH 00/16] Fix RMRR Jan Beulich
2015-06-11  8:42   ` Tian, Kevin
2015-06-11  9:06     ` Chen, Tiejun
2015-06-11 12:52 ` Tim Deegan
2015-06-12  2:10   ` Chen, Tiejun
2015-06-12  8:04     ` Jan Beulich
2015-06-12  8:20       ` Chen, Tiejun

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=557A7CA7.9000305@intel.com \
    --to=tiejun.chen@intel.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=kevin.tian@intel.com \
    --cc=stefano.stabellini@citrix.com \
    --cc=tim@xen.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    --cc=yang.z.zhang@intel.com \
    /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.