All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Li Qiang <liq3ea@gmail.com>
Cc: Li Qiang <liq3ea@163.com>, Jiri Slaby <jslaby@suse.cz>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Qemu Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH v2 3/3] edu: uses uint64_t in dma operation
Date: Mon, 22 Apr 2019 18:29:14 +0200	[thread overview]
Message-ID: <c82b3a97-b4ad-b202-3676-67a6198951d1@redhat.com> (raw)
In-Reply-To: <CAKXe6SKKkao0gnGdvDWXbs9AG6uXLkeMybLH-7AP2-CiP7EEdQ@mail.gmail.com>

On 4/22/19 3:21 AM, Li Qiang wrote:
> 
> 
> Philippe Mathieu-Daudé <philmd@redhat.com <mailto:philmd@redhat.com>> 于
> 2019年4月21日周日 下午6:32写道:
> 
>     On 4/20/19 6:14 PM, Li Qiang wrote:
>     > The dma related variable is dma_addr_t, it is uint64_t in
>     > x64 platform. Change these usage from uint32_to uint64_t to
>     > avoid trancation.
> 
>     "to avoid address truncation"?
> 
> 
> 
> The dma.dst/src/cnt..is from guest and is 64-bits. But in 'edu_dma_timer',
> it is assigned to uint32_t, If it is 0xffffffff 00000000, it will be ok
> by the check
> but it is of course not allowed. 
> 
> Though this is just an edu device, I think we should avoid this. 

I agree with you, I was just trying to correct your English ;)

> Thanks,
> Li Qiang
> 
>  
> 
>     >
>     > Signed-off-by: Li Qiang <liq3ea@163.com <mailto:liq3ea@163.com>>
>     > ---
>     > Change since v1:
>     > Fix format compile error on Windows
>     >
>     >  hw/misc/edu.c | 15 ++++++++-------
>     >  1 file changed, 8 insertions(+), 7 deletions(-)
>     >
>     > diff --git a/hw/misc/edu.c b/hw/misc/edu.c
>     > index 4018dddcb8..f4a6d5f1c5 100644
>     > --- a/hw/misc/edu.c
>     > +++ b/hw/misc/edu.c
>     > @@ -98,23 +98,24 @@ static void edu_lower_irq(EduState *edu,
>     uint32_t val)
>     >      }
>     >  }
>     > 
>     > -static bool within(uint32_t addr, uint32_t start, uint32_t end)
>     > +static bool within(uint64_t addr, uint64_t start, uint64_t end)
> 
>     OK.
> 
>     >  {
>     >      return start <= addr && addr < end;
>     >  }
>     > 
>     > -static void edu_check_range(uint32_t addr, uint32_t size1,
>     uint32_t start,
>     > +static void edu_check_range(uint64_t addr, uint64_t size1,
>     uint64_t start,
>     >                  uint32_t size2)
> 
>     OK for addr. MMIO range is 1MiB so you can keep uint32_t for
>     size1/size2. Up to the maintainer (personally I'd prefer keep u32).
> 
>     Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com
>     <mailto:philmd@redhat.com>>
> 
>     >  {
>     > -    uint32_t end1 = addr + size1;
>     > -    uint32_t end2 = start + size2;
>     > +    uint64_t end1 = addr + size1;
>     > +    uint64_t end2 = start + size2;
>     > 
>     >      if (within(addr, start, end2) &&
>     >              end1 > addr && within(end1, start, end2)) {
>     >          return;
>     >      }
>     > 
>     > -    hw_error("EDU: DMA range 0x%.8x-0x%.8x out of bounds
>     (0x%.8x-0x%.8x)!",
>     > +    hw_error("EDU: DMA range 0x%016"PRIx64"-0x%016"PRIx64
>     > +             " out of bounds (0x%016"PRIx64"-0x%016"PRIx64")!",
>     >              addr, end1 - 1, start, end2 - 1);
>     >  }
>     > 
>     > @@ -139,13 +140,13 @@ static void edu_dma_timer(void *opaque)
>     >      }
>     > 
>     >      if (EDU_DMA_DIR(edu->dma.cmd) == EDU_DMA_FROM_PCI) {
>     > -        uint32_t dst = edu->dma.dst;
>     > +        uint64_t dst = edu->dma.dst;
>     >          edu_check_range(dst, edu->dma.cnt, DMA_START, DMA_SIZE);
>     >          dst -= DMA_START;
>     >          pci_dma_read(&edu->pdev, edu_clamp_addr(edu, edu->dma.src),
>     >                  edu->dma_buf + dst, edu->dma.cnt);
>     >      } else {
>     > -        uint32_t src = edu->dma.src;
>     > +        uint64_t src = edu->dma.src;
>     >          edu_check_range(src, edu->dma.cnt, DMA_START, DMA_SIZE);
>     >          src -= DMA_START;
>     >          pci_dma_write(&edu->pdev, edu_clamp_addr(edu, edu->dma.dst),
>     >
> 

WARNING: multiple messages have this Message-ID (diff)
From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Li Qiang <liq3ea@gmail.com>
Cc: Jiri Slaby <jslaby@suse.cz>, Li Qiang <liq3ea@163.com>,
	Qemu Developers <qemu-devel@nongnu.org>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 3/3] edu: uses uint64_t in dma operation
Date: Mon, 22 Apr 2019 18:29:14 +0200	[thread overview]
Message-ID: <c82b3a97-b4ad-b202-3676-67a6198951d1@redhat.com> (raw)
Message-ID: <20190422162914.FPWCU_FYLCPMWiQQMERA7VIu78ZPtadxQaS1iaOu-v8@z> (raw)
In-Reply-To: <CAKXe6SKKkao0gnGdvDWXbs9AG6uXLkeMybLH-7AP2-CiP7EEdQ@mail.gmail.com>

On 4/22/19 3:21 AM, Li Qiang wrote:
> 
> 
> Philippe Mathieu-Daudé <philmd@redhat.com <mailto:philmd@redhat.com>> 于
> 2019年4月21日周日 下午6:32写道:
> 
>     On 4/20/19 6:14 PM, Li Qiang wrote:
>     > The dma related variable is dma_addr_t, it is uint64_t in
>     > x64 platform. Change these usage from uint32_to uint64_t to
>     > avoid trancation.
> 
>     "to avoid address truncation"?
> 
> 
> 
> The dma.dst/src/cnt..is from guest and is 64-bits. But in 'edu_dma_timer',
> it is assigned to uint32_t, If it is 0xffffffff 00000000, it will be ok
> by the check
> but it is of course not allowed. 
> 
> Though this is just an edu device, I think we should avoid this. 

I agree with you, I was just trying to correct your English ;)

> Thanks,
> Li Qiang
> 
>  
> 
>     >
>     > Signed-off-by: Li Qiang <liq3ea@163.com <mailto:liq3ea@163.com>>
>     > ---
>     > Change since v1:
>     > Fix format compile error on Windows
>     >
>     >  hw/misc/edu.c | 15 ++++++++-------
>     >  1 file changed, 8 insertions(+), 7 deletions(-)
>     >
>     > diff --git a/hw/misc/edu.c b/hw/misc/edu.c
>     > index 4018dddcb8..f4a6d5f1c5 100644
>     > --- a/hw/misc/edu.c
>     > +++ b/hw/misc/edu.c
>     > @@ -98,23 +98,24 @@ static void edu_lower_irq(EduState *edu,
>     uint32_t val)
>     >      }
>     >  }
>     > 
>     > -static bool within(uint32_t addr, uint32_t start, uint32_t end)
>     > +static bool within(uint64_t addr, uint64_t start, uint64_t end)
> 
>     OK.
> 
>     >  {
>     >      return start <= addr && addr < end;
>     >  }
>     > 
>     > -static void edu_check_range(uint32_t addr, uint32_t size1,
>     uint32_t start,
>     > +static void edu_check_range(uint64_t addr, uint64_t size1,
>     uint64_t start,
>     >                  uint32_t size2)
> 
>     OK for addr. MMIO range is 1MiB so you can keep uint32_t for
>     size1/size2. Up to the maintainer (personally I'd prefer keep u32).
> 
>     Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com
>     <mailto:philmd@redhat.com>>
> 
>     >  {
>     > -    uint32_t end1 = addr + size1;
>     > -    uint32_t end2 = start + size2;
>     > +    uint64_t end1 = addr + size1;
>     > +    uint64_t end2 = start + size2;
>     > 
>     >      if (within(addr, start, end2) &&
>     >              end1 > addr && within(end1, start, end2)) {
>     >          return;
>     >      }
>     > 
>     > -    hw_error("EDU: DMA range 0x%.8x-0x%.8x out of bounds
>     (0x%.8x-0x%.8x)!",
>     > +    hw_error("EDU: DMA range 0x%016"PRIx64"-0x%016"PRIx64
>     > +             " out of bounds (0x%016"PRIx64"-0x%016"PRIx64")!",
>     >              addr, end1 - 1, start, end2 - 1);
>     >  }
>     > 
>     > @@ -139,13 +140,13 @@ static void edu_dma_timer(void *opaque)
>     >      }
>     > 
>     >      if (EDU_DMA_DIR(edu->dma.cmd) == EDU_DMA_FROM_PCI) {
>     > -        uint32_t dst = edu->dma.dst;
>     > +        uint64_t dst = edu->dma.dst;
>     >          edu_check_range(dst, edu->dma.cnt, DMA_START, DMA_SIZE);
>     >          dst -= DMA_START;
>     >          pci_dma_read(&edu->pdev, edu_clamp_addr(edu, edu->dma.src),
>     >                  edu->dma_buf + dst, edu->dma.cnt);
>     >      } else {
>     > -        uint32_t src = edu->dma.src;
>     > +        uint64_t src = edu->dma.src;
>     >          edu_check_range(src, edu->dma.cnt, DMA_START, DMA_SIZE);
>     >          src -= DMA_START;
>     >          pci_dma_write(&edu->pdev, edu_clamp_addr(edu, edu->dma.dst),
>     >
> 


  reply	other threads:[~2019-04-22 16:35 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-20 16:14 [Qemu-devel] [PATCH v2 0/3] hw: edu: some fixes Li Qiang
2019-04-20 16:14 ` Li Qiang
2019-04-20 16:14 ` [Qemu-devel] [PATCH v2 1/3] edu: mmio: set 'max_access_size' to 8 Li Qiang
2019-04-20 16:14   ` Li Qiang
2019-04-21 10:28   ` Philippe Mathieu-Daudé
2019-04-22  1:17     ` Li Qiang
2019-04-22  1:17       ` Li Qiang
2019-04-22 16:27       ` Philippe Mathieu-Daudé
2019-04-22 16:27         ` Philippe Mathieu-Daudé
2019-04-23  3:50         ` Li Qiang
2019-04-23  3:50           ` Li Qiang
2019-04-20 16:14 ` [Qemu-devel] [PATCH v2 2/3] edu: mmio: allow mmio read dispatch accept 8 bytes Li Qiang
2019-04-20 16:14   ` Li Qiang
2019-04-21 10:44   ` Philippe Mathieu-Daudé
2019-04-22  1:22     ` Li Qiang
2019-04-22  1:22       ` Li Qiang
2019-04-20 16:14 ` [Qemu-devel] [PATCH v2 3/3] edu: uses uint64_t in dma operation Li Qiang
2019-04-20 16:14   ` Li Qiang
2019-04-21 10:32   ` Philippe Mathieu-Daudé
2019-04-22  1:21     ` Li Qiang
2019-04-22  1:21       ` Li Qiang
2019-04-22 16:29       ` Philippe Mathieu-Daudé [this message]
2019-04-22 16:29         ` Philippe Mathieu-Daudé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c82b3a97-b4ad-b202-3676-67a6198951d1@redhat.com \
    --to=philmd@redhat.com \
    --cc=jslaby@suse.cz \
    --cc=liq3ea@163.com \
    --cc=liq3ea@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.