[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Hight Processor time of Socket communciation
From: |
Jiahuan Zhang |
Subject: |
Re: [Qemu-devel] Hight Processor time of Socket communciation |
Date: |
Wed, 19 Apr 2017 11:25:07 +0200 |
On 19 April 2017 at 11:15, Peter Maydell <address@hidden> wrote:
> On 19 April 2017 at 09:56, Jiahuan Zhang <address@hidden> wrote:
> > Do you mean that it is reasonable for QEMU emulation consumes high CPU
> time
> > when doing host-guest interaction, since the interaction calls many QEMU
> > codes in the background?
>
> > Since my guest app is rather simple and no while() is included,
> according to
> > your words,
> > can I conclude that the high processor time is cause by the callbacks for
> > guest to host data transfer?
>
> What is happening is that the guest kernel's serial driver
> has a loop that (simplified) looks like this:
>
> do {
> if (pl011_read(REG_FR) & FR_TXFF)
> break; /* fifo full, try again later */
> pl011_write(buffer[x], REG_DR); /* send one byte */
> x++;
> } while (x != len);
>
> This is a lot of guest CPU instructions (and two callouts
> to QEMU's device emulation) for every single byte.
>
> Hi, no, I am not using any kernel driver and I only test the guest to host
data transfer.
I need the kernel transparent guest-host communication.
The code is in this way.
/***************************************************************/*
int main() {
const char *filename = "image_set/Snake_River_(5mb).jpg";
/* get the file size */
struct stat buf;
uint32_t zero = stat(filename, &buf);
if (zero == 0)
printf("image size = %d \n", buf.st_size);
else
printf("stat() failed");
/* open the file */
uint32_t fd = open(filename, O_RDONLY);
if(!fd){
printf("could not open file.\n");
close(fd);
return 0;
}
/* read file into s */
while((ret_in = read(fd, &s[0], BUF_SIZE)) > 0){
write_to_uart(s, ret_in);
}
}
/*
* write_to_uart(): write data to serial port
*/
void write_to_uart(char* out, uint32_t writeSize){
int i;
for(i=0; i<writeSize; i++){
*UART1 =(unsigned char)(*(out+i));
}
}
regards,
Huan
> >> You will likely get better throughput if you use the 'virt' board
> >> where you can use the virtio-serial device which can send
> >> data more efficiently.
>
> > Here, can I understand your statement in this way,
> > a transmit buffer in the serial device for guest to host data transfer
> > may reduce the processor time, and in turn, increase the throughput?
>
> The reason virtio-serial is faster is because the guest
> kernel driver can essentially tell QEMU
> "the data is in guest memory at address X length L"
> and then QEMU takes all that data at once. This is much
> more efficient.
>
> thanks
> -- PMM
>
- [Qemu-devel] Hight Processor time of Socket communciation, Jiahuan Zhang, 2017/04/18
- Re: [Qemu-devel] Hight Processor time of Socket communciation, Peter Maydell, 2017/04/18
- Re: [Qemu-devel] Hight Processor time of Socket communciation, Jiahuan Zhang, 2017/04/19
- Re: [Qemu-devel] Hight Processor time of Socket communciation, Peter Maydell, 2017/04/19
- Re: [Qemu-devel] Hight Processor time of Socket communciation,
Jiahuan Zhang <=
- Re: [Qemu-devel] Hight Processor time of Socket communciation, Peter Maydell, 2017/04/19
- Re: [Qemu-devel] Hight Processor time of Socket communciation, Jiahuan Zhang, 2017/04/19
- Re: [Qemu-devel] Hight Processor time of Socket communciation, Peter Maydell, 2017/04/19
- Re: [Qemu-devel] Hight Processor time of Socket communciation, Jiahuan Zhang, 2017/04/19
- Re: [Qemu-devel] Hight Processor time of Socket communciation, Peter Maydell, 2017/04/19