Skip to content

Commit

Permalink
ioreq: don't wrongly claim "success" in ioreq_send_buffered()
Browse files Browse the repository at this point in the history
Returning a literal number is a bad idea anyway when all other returns
use IOREQ_STATUS_* values. The function is dead on Arm, and mapping to
X86EMUL_OKAY is surely wrong on x86.

Fixes: f6bf39f ("x86/hvm: add support for broadcast of buffered ioreqs...")
Signed-off-by: Jan Beulich <[email protected]>
Reviewed-by: Julien Grall <[email protected]>
  • Loading branch information
jbeulich committed Oct 8, 2024
1 parent 011814b commit 2e0b545
Showing 1 changed file with 2 additions and 2 deletions.
4 changes: 2 additions & 2 deletions xen/common/ioreq.c
Original file line number Diff line number Diff line change
Expand Up @@ -1175,15 +1175,15 @@ static int ioreq_send_buffered(struct ioreq_server *s, ioreq_t *p)
return IOREQ_STATUS_UNHANDLED;

/*
* Return 0 for the cases we can't deal with:
* Return UNHANDLED for the cases we can't deal with:
* - 'addr' is only a 20-bit field, so we cannot address beyond 1MB
* - we cannot buffer accesses to guest memory buffers, as the guest
* may expect the memory buffer to be synchronously accessed
* - the count field is usually used with data_is_ptr and since we don't
* support data_is_ptr we do not waste space for the count field either
*/
if ( (p->addr > 0xfffffUL) || p->data_is_ptr || (p->count != 1) )
return 0;
return IOREQ_STATUS_UNHANDLED;

switch ( p->size )
{
Expand Down

0 comments on commit 2e0b545

Please sign in to comment.