On Tue, Dec 09, 2014 at 08:33:56AM +, Jan Beulich wrote:
> >>> On 09.12.14 at 02:06, wrote:
> Also how does this work with 32-bit dom0s? Is there a need to use the
> compat layer?
> >>>
> >>> Are you saying in xsm case? Others?
> >>>
> >>> Actually this new DOMCTL is similar with XEN
>>> On 09.12.14 at 02:06, wrote:
Also how does this work with 32-bit dom0s? Is there a need to use the
compat layer?
>>>
>>> Are you saying in xsm case? Others?
>>>
>>> Actually this new DOMCTL is similar with XEN_DOMCTL_assign_device in some
>>> senses but I don't see such an issue you'
>>> On 09.12.14 at 03:38, wrote:
> On 2014/12/8 16:43, Jan Beulich wrote:
> On 08.12.14 at 07:06, wrote:
>>> I take a quick look at this but looks we have no this exact value that
>>> we can get directly.
>>
>> You need some upper bound. Whether you introduce a properly
>
> In theory, we may
On 2014/12/8 16:43, Jan Beulich wrote:
On 08.12.14 at 07:06, wrote:
On 2014/12/4 23:33, Jan Beulich wrote:
On 01.12.14 at 10:24, wrote:
Looks this could be fine,
d->arch.hvm_domain.pci_force = xdsr->flags & PCI_DEV_RDM_CHECK;
Which is correct only because PCI_DEV_RDM_CHECK happens to be
1
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
struct pci_seg {
struct list_head alldevs_list;
@@ -1553,6 +1554,44 @@ int iommu_do_pci_domctl(
}
break;
+case XEN_DOMCTL_set_r
On Mon, Dec 08, 2014 at 11:16:07AM +0800, Chen, Tiejun wrote:
>
> On 2014/12/3 3:39, Konrad Rzeszutek Wilk wrote:
> >On Mon, Dec 01, 2014 at 05:24:20PM +0800, Tiejun Chen wrote:
> >>This should be based on a new parameter globally, 'pci_rdmforce'.
> >>
> >>pci_rdmforce = 1 => Of course this should
>>> On 08.12.14 at 07:06, wrote:
> On 2014/12/4 23:33, Jan Beulich wrote:
> On 01.12.14 at 10:24, wrote:
> Looks this could be fine,
>
> d->arch.hvm_domain.pci_force = xdsr->flags & PCI_DEV_RDM_CHECK;
Which is correct only because PCI_DEV_RDM_CHECK happens to be
1. Such hidden dependencies
On 2014/12/4 23:33, Jan Beulich wrote:
On 01.12.14 at 10:24, wrote:
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
Please don't - we use bool_t in the hypervisor, not bool. The header
Yes.
only exist
On 2014/12/3 3:39, Konrad Rzeszutek Wilk wrote:
On Mon, Dec 01, 2014 at 05:24:20PM +0800, Tiejun Chen wrote:
This should be based on a new parameter globally, 'pci_rdmforce'.
pci_rdmforce = 1 => Of course this should be 0 by default.
'1' means we should force check to reserve all ranges. If f
On 2014/12/2 16:33, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Monday, December 01, 2014 5:24 PM
This should be based on a new parameter globally, 'pci_rdmforce'.
pci_rdmforce = 1 => Of course this should be 0 by default.
'1' means we should force check to reserve all ranges. If failed
VM wou
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, December 04, 2014 11:33 PM
> > +if ( pcidevs == NULL )
> > +{
> > +rcu_unlock_domain(d);
> > +return -ENOMEM;
> > +}
> > +
> > +if ( copy_from_guest(pcide
>>> On 01.12.14 at 10:24, wrote:
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
Please don't - we use bool_t in the hypervisor, not bool. The header
only exists for source code shared with the too
On Mon, Dec 01, 2014 at 05:24:20PM +0800, Tiejun Chen wrote:
> This should be based on a new parameter globally, 'pci_rdmforce'.
>
> pci_rdmforce = 1 => Of course this should be 0 by default.
>
> '1' means we should force check to reserve all ranges. If failed
> VM wouldn't be created successfull
> From: Chen, Tiejun
> Sent: Monday, December 01, 2014 5:24 PM
>
> This should be based on a new parameter globally, 'pci_rdmforce'.
>
> pci_rdmforce = 1 => Of course this should be 0 by default.
>
> '1' means we should force check to reserve all ranges. If failed
> VM wouldn't be created succes
14 matches
Mail list logo
