Hi Alex,
I will use workable state support flag
to let user know whether the kenerl support block feature.
And make configure space writing and ioctl function blocked.
And what of my suggestion that a user may desire to poll the state of
the device?
I will also add a poll function to vfio_fop
On Wed, 13 Jul 2016 09:04:16 +0800
Zhou Jie wrote:
> Hi Alex,
>
> >> I will use workable state support flag
> >> to let user know whether the kenerl support block feature.
> >> And make configure space writing and ioctl function blocked.
> >
> > And what of my suggestion that a user may desire
Hi Alex,
I will use workable state support flag
to let user know whether the kenerl support block feature.
And make configure space writing and ioctl function blocked.
And what of my suggestion that a user may desire to poll the state of
the device?
I will also add a poll function to vfio_fop
On Tue, 12 Jul 2016 09:42:21 +0800
Zhou Jie wrote:
> Hi Alex,
>
> >>> The variable clearly isn't visible to the user, so the user can know
> >>> whether the kernel supports this feature, but not whether the feature
> >>> is currently active. Perhaps there's no way to avoid races completely,
> >
Hi Alex,
The variable clearly isn't visible to the user, so the user can know
whether the kernel supports this feature, but not whether the feature
is currently active. Perhaps there's no way to avoid races completely,
but don't you expect that if we define that certain operations are
blocked a
On Sun, 10 Jul 2016 09:28:41 +0800
Zhou Jie wrote:
> Hi Alex,
>
> > The variable clearly isn't visible to the user, so the user can know
> > whether the kernel supports this feature, but not whether the feature
> > is currently active. Perhaps there's no way to avoid races completely,
> > but d
Hi Alex,
The variable clearly isn't visible to the user, so the user can know
whether the kernel supports this feature, but not whether the feature
is currently active. Perhaps there's no way to avoid races completely,
but don't you expect that if we define that certain operations are
blocked a
On Fri, 8 Jul 2016 09:38:50 +0800
Zhou Jie wrote:
> Hi Alex,
>
> > The following code will be modified.
> > 1. vfio_pci_ioctl
> >add a flag in vfio_device_info for workable_state support
> >return workable_state in "struct vfio_pci_device" when user get info
> >
>
Hi Alex,
The following code will be modified.
1. vfio_pci_ioctl
add a flag in vfio_device_info for workable_state support
return workable_state in "struct vfio_pci_device" when user get info
Seems like two flags are required, one to indicate the presence of this
feature and another to in
On Wed, 6 Jul 2016 10:01:28 +0800
Zhou Jie wrote:
> Hi Alex,
>
> > Due to weekend and holiday in my country, there were zero regular
> > working hours between your emails.
> I wish you had a good time.
>
> >>> The following code will be modified.
> >>> 1. vfio_pci_ioctl
> >>>add a flag in
Hi Alex,
Due to weekend and holiday in my country, there were zero regular
working hours between your emails.
I wish you had a good time.
The following code will be modified.
1. vfio_pci_ioctl
add a flag in vfio_device_info for workable_state support
return workable_state in "struct vfi
On Tue, 5 Jul 2016 09:36:27 +0800
Zhou Jie wrote:
> ping
Due to weekend and holiday in my country, there were zero regular
working hours between your emails.
> On 2016/7/3 12:00, Zhou Jie wrote:
> > Hi Alex,
> >
> > On 2016/6/30 9:45, Zhou Jie wrote:
> >> Hi Alex,
> >>
> >> On 2016/6/30 2:22
ping
On 2016/7/3 12:00, Zhou Jie wrote:
Hi Alex,
On 2016/6/30 9:45, Zhou Jie wrote:
Hi Alex,
On 2016/6/30 2:22, Alex Williamson wrote:
On Wed, 29 Jun 2016 16:54:05 +0800
Zhou Jie wrote:
Hi Alex,
And yet we have struct pci_dev.broken_intx_masking and we test for
working DisINTx via pci_i
Hi Alex,
On 2016/6/30 9:45, Zhou Jie wrote:
Hi Alex,
On 2016/6/30 2:22, Alex Williamson wrote:
On Wed, 29 Jun 2016 16:54:05 +0800
Zhou Jie wrote:
Hi Alex,
And yet we have struct pci_dev.broken_intx_masking and we test for
working DisINTx via pci_intx_mask_supported() rather than simply
lo
Hi Alex,
On 2016/6/30 2:22, Alex Williamson wrote:
On Wed, 29 Jun 2016 16:54:05 +0800
Zhou Jie wrote:
Hi Alex,
And yet we have struct pci_dev.broken_intx_masking and we test for
working DisINTx via pci_intx_mask_supported() rather than simply
looking for a PCIe device. Some devices are bro
On Wed, 29 Jun 2016 16:54:05 +0800
Zhou Jie wrote:
> Hi Alex,
>
> > And yet we have struct pci_dev.broken_intx_masking and we test for
> > working DisINTx via pci_intx_mask_supported() rather than simply
> > looking for a PCIe device. Some devices are broken and some simply
> > don't follow the
Hi Alex,
And yet we have struct pci_dev.broken_intx_masking and we test for
working DisINTx via pci_intx_mask_supported() rather than simply
looking for a PCIe device. Some devices are broken and some simply
don't follow the spec, so you're going to need to deal with that or
exclude those devic
On Tue, 28 Jun 2016 13:27:21 +0800
Zhou Jie wrote:
> Hi Alex,
>
> On 2016/6/28 11:58, Alex Williamson wrote:
> > On Tue, 28 Jun 2016 11:26:33 +0800
> > Zhou Jie wrote:
> >
> >> Hi Alex,
> >>
> >>> The INTx/MSI part needs further definition for the user. Are we
> >>> actually completely tea
Hi Alex,
On 2016/6/28 11:58, Alex Williamson wrote:
On Tue, 28 Jun 2016 11:26:33 +0800
Zhou Jie wrote:
Hi Alex,
The INTx/MSI part needs further definition for the user. Are we
actually completely tearing down interrupts with the expectation that
the user will re-enable them or are we just
On Tue, 28 Jun 2016 11:26:33 +0800
Zhou Jie wrote:
> Hi Alex,
>
> > The INTx/MSI part needs further definition for the user. Are we
> > actually completely tearing down interrupts with the expectation that
> > the user will re-enable them or are we just masking them such that the
> > user needs
Hi Alex,
The INTx/MSI part needs further definition for the user. Are we
actually completely tearing down interrupts with the expectation that
the user will re-enable them or are we just masking them such that the
user needs to unmask? Also note that not all devices support DisINTx.
After re
On Sat, 25 Jun 2016 09:24:19 +0800
Zhou Jie wrote:
> Hi Alex,
>
> > We should never depend on the guest driver to behave in a certain way,
> > but we need to prioritize what that actually means. vfio in the kernel
> > has a responsibility first and foremost to the host kernel. User owned
> > d
Hi Alex,
We should never depend on the guest driver to behave in a certain way,
but we need to prioritize what that actually means. vfio in the kernel
has a responsibility first and foremost to the host kernel. User owned
devices cannot be allowed to exploit or interfere with the host
regardle
On Wed, 22 Jun 2016 15:49:41 +0800
Zhou Jie wrote:
> Hi Alex,
>
> On 2016/6/22 13:45, Zhou Jie wrote:
> > Hi Alex,
> >
> >>>
> >>> In vfio I have some questions.
> >>> 1. How can I disable the access by mmap?
> >>> We can disable all access to vfio fd by returning a EAGAIN error
> >>>
On Wed, 22 Jun 2016 13:45:10 +0800
Zhou Jie wrote:
> Hi Alex,
>
> >>
> >> In vfio I have some questions.
> >> 1. How can I disable the access by mmap?
> >> We can disable all access to vfio fd by returning a EAGAIN error
> >> if user try to access it during the reset period until the hos
Hi Alex,
On 2016/6/22 13:45, Zhou Jie wrote:
Hi Alex,
In vfio I have some questions.
1. How can I disable the access by mmap?
We can disable all access to vfio fd by returning a EAGAIN error
if user try to access it during the reset period until the host
reset finished.
But ab
Hi Alex,
In vfio I have some questions.
1. How can I disable the access by mmap?
We can disable all access to vfio fd by returning a EAGAIN error
if user try to access it during the reset period until the host
reset finished.
But about the bar region which is maped by vfio_pci_m
On Wed, 22 Jun 2016 11:28:50 +0800
Zhou Jie wrote:
> Hi Alex,
>
> >> Hi Alex,
> >> on kernel side, I think if we don't trust the user behaviors, we
> >> should
> >> disable the access of vfio-pci interface once vfio-pci driver got the
> >> error_detected,
> >> we should disable all acc
Hi Alex,
Hi Alex,
on kernel side, I think if we don't trust the user behaviors, we
should
disable the access of vfio-pci interface once vfio-pci driver got the
error_detected,
we should disable all access to vfio fd regardless whether the vfio-pci
was assigned to a VM, we also can re
On Tue, 21 Jun 2016 20:41:32 +0800
Chen Fan wrote:
> On 2016年06月21日 11:13, Alex Williamson wrote:
> > On Tue, 21 Jun 2016 10:16:25 +0800
> > Zhou Jie wrote:
> >
> >> Hi, Alex
> >>
> >>> I was really hoping to hear your opinion, or at least some further
> >>> discussion of pros and cons rathe
On 2016年06月21日 11:13, Alex Williamson wrote:
On Tue, 21 Jun 2016 10:16:25 +0800
Zhou Jie wrote:
Hi, Alex
I was really hoping to hear your opinion, or at least some further
discussion of pros and cons rather than simply parroting back my idea.
I understand.
My current thinking is that a re
On Tue, 21 Jun 2016 10:16:25 +0800
Zhou Jie wrote:
> Hi, Alex
>
> > I was really hoping to hear your opinion, or at least some further
> > discussion of pros and cons rather than simply parroting back my idea.
> I understand.
>
> > My current thinking is that a resume notifier to userspace is
Hi, Alex
I was really hoping to hear your opinion, or at least some further
discussion of pros and cons rather than simply parroting back my idea.
I understand.
My current thinking is that a resume notifier to userspace is poorly
defined, it's not clear what the user can and cannot do between
On Mon, 20 Jun 2016 15:41:03 +0800
Zhou Jie wrote:
> ping
>
> On 2016/6/12 10:38, Zhou Jie wrote:
> > Hi, Alex
> >
> >> It seems like we have a number of questions open in the thread with MST
> >> from the previous version, particularly whether we should actually drop
> >> the resume notifier
ping
On 2016/6/12 10:38, Zhou Jie wrote:
Hi, Alex
It seems like we have a number of questions open in the thread with MST
from the previous version, particularly whether we should actually drop
the resume notifier and block the reset in the kernel. The concern
being that it's not very well sp
Hi, Alex
It seems like we have a number of questions open in the thread with MST
from the previous version, particularly whether we should actually drop
the resume notifier and block the reset in the kernel. The concern
being that it's not very well specified what we can and cannot do
between t
On Fri, 27 May 2016 10:12:11 +0800
Zhou Jie wrote:
> From: Chen Fan
>
> For supporting aer recovery, host and guest would run the same aer
> recovery code, that would do the secondary bus reset if the error
> is fatal, the aer recovery process:
> 1. error_detected
> 2. reset_link (if fatal)
From: Chen Fan
For supporting aer recovery, host and guest would run the same aer
recovery code, that would do the secondary bus reset if the error
is fatal, the aer recovery process:
1. error_detected
2. reset_link (if fatal)
3. slot_reset/mmio_enabled
4. resume
It indicates that host w
38 matches
Mail list logo
