|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [VTD][PATCH] Don't allow assigning the same device twice
That's a lot better. I'll take the Xen portion but the tools changes need
more work:
The PCI-string parsing code cannot be placed in xc_private.[ch] and then
exported outside the library. Also using strtok() is invalid as it is not
thread-safe. You should use strtok_r() instead. I think you can get rid of
pci_count() altogether and have first_bdf/next_bdf return a boolean whether
they have reached the end of the string or not (strtok_r will return NULL
when the last token has been parsed). Then the caller would use them
something like:
for (done = first_bdf(); !done; done = next_bdf())
Given the small amount of code for first_bdf/next_bdf, and given that
pci_count can be got rid of entirely, I would just duplicate that simple
strtok code in both the python wrapper and ioemu. I wouldn't add that rather
specific parsing code to libxc.
Please fix up and re-spin the tools part of the patch.
-- Keir
On 18/10/07 02:51, "Han, Weidong" <weidong.han@xxxxxxxxx> wrote:
> Keir,
>
> Resend the patch. This patch is implemented according to your
> suggestion. Asssigns device in xend before starting ioemu, and add the
> check on DOMCTL_assign_device hypercall. Thanks.
>
> -- Weidong
>
> Keir Fraser wrote:
>> On 16/10/07 03:04, "Han, Weidong" <weidong.han@xxxxxxxxx> wrote:
>>
>>>> The DOMCTL_assign_device should check whether the device is already
>>>> assigned. This has the benefit that it can atomically
>>>> check-and-allocate, under the domctl lock.
>>>>
>>>> You'll have to work out how to propagate DOMCTL_assign_device
>>>> failure to the user. Either you have to get the error out of ioemu,
>>>> or perhaps you can assign the device in xend before starting ioemu.
>>>
>>> Yes, adding the check on DOMCTL_assign_device is simple, but I didn't
>>> find a good way to propagate DOMCTL_assign_device failure to user.
>>> This patch adds the check in xend before starting ioemu. In addtion,
>>> adding the check in Xend can prompt user on the screen when the
>>> device has already been assigned. Thanks.
>>
>> Well, that's too bad because I won't take the original patch. Why
>> can't the device be assigned by xend?
>>
>> -- Keir
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-devel] [VTD][PATCH] Don't allow assigning the same device twice without release the first assignment, Han, Weidong
- Re: [Xen-devel] [VTD][PATCH] Don't allow assigning the same device twice without release the first assignment, Keir Fraser
- RE: [Xen-devel] [VTD][PATCH] Don't allow assigning the same device twice without release the first assignment, Han, Weidong
- Re: [Xen-devel] [VTD][PATCH] Don't allow assigning the same device twice without release the first assignment, Keir Fraser
- RE: [Xen-devel] [VTD][PATCH] Don't allow assigning the same device twice without release the first assignment, Han, Weidong
- RE: [Xen-devel] [VTD][PATCH] Don't allow assigning the same device twice without release the first assignment, Han, Weidong
- Re: [Xen-devel] [VTD][PATCH] Don't allow assigning the same device twice without release the first assignment,
Keir Fraser <=
- RE: [Xen-devel] [VTD][PATCH] Don't allow assigning the samedevice twice without release the first assignment, Han, Weidong
- Re: [Xen-devel] [VTD][PATCH] Don't allow assigning the samedevice twice without release the first assignment, Keir Fraser
- RE: [Xen-devel] [VTD][PATCH] Don't allow assigning the samedevice twice without release the first assignment, Han, Weidong
|
|
|
|
|