>>> On 18.05.18 at 15:51, <paul.durr...@citrix.com> wrote:
>> Sent: 18 May 2018 14:34
>> To: Paul Durrant <paul.durr...@citrix.com>
>> >>> On 18.05.18 at 15:00, <paul.durr...@citrix.com> wrote:
>> > + QLIST_FOREACH(xendev, &state->dev_list, entry) {
>> > + unsigned int i;
>> > + uint32_t tmp;
>> > +
>> > + if (xendev->sbdf != sbdf) {
>> > + continue;
>> > + }
>> > +
>> > + if (!req->data_is_ptr) {
>> > + if (req->dir == IOREQ_READ) {
>> > + for (i = 0; i < req->count; i++) {
>> > + rw_config_req_item(xendev, req, i, &tmp);
>> > + req->data = tmp;
>> > + }
>> > + } else if (req->dir == IOREQ_WRITE) {
>> > + for (i = 0; i < req->count; i++) {
>> > + tmp = req->data;
>> > + rw_config_req_item(xendev, req, i, &tmp);
>> > + }
>> > + }
>>
>> Wouldn't it be more sensible to fail req->count != 1 requests here?
>>
>
> I'm wondering whether we'd want to handle count > 1 once we allow MMCONFIG
> accesses though. I guess it would be easier just to defer that.
For the data_is_ptr case - sure. But here? Or wait - are you thinking about
REP STOS (and the relatively useless REP LODS)?
Jan
