from:"mattias"

Control: found 1068134 7.3-1
Control: notfound 1068134 7.3-2

The bug reported here is already fixed in the version for which the bug
was reported.

This bug was present in the previous version. The current version was
uploaded precisely to fix the problem reported.

Previous version (7.3-1) had

Depends: libglobus-common0 (>= 15)

Current version (7.3-2) has

Depends: libglobus-common0 (>= 15) | libglobus-common0t64 (>= 15)

I.e. it does not depend only on the old package name, but on either the
new or the old. The package is therefore not blocking the t64
transition.

    Mattias

sön 2024-03-31 klockan 17:41 +0200 skrev Sebastian Ramacher:
> Source: globus-gram-job-manager-scripts
> Version: 7.3-2
> Severity: serious
> X-Debbugs-Cc: sramac...@debian.org
> 
> globus-gram-job-manager-scripts builds an Architecture: all packages
> depending on a library package involved in the time_t 64 transition.
> This dependency needs to be updated.
> 
> Cheers
> --
> Sebastian Ramacher
> 
> VARNING: Klicka inte på länkar och öppna inte bilagor om du inte
> känner igen avsändaren och vet att innehållet är säkert.
> CAUTION: Do not click on links or open attachments unless you
> recognise the sender and know the content is safe.



signature.asc
Description: This is a digitally signed message part

Bug#1068134: globus-gram-job-manager-scripts: arch:all package depends on pre-t64 library

Control: found 1068134 7.3-1
Control: notfound 1068134 7.3-2

The bug reported here is already fixed in the version for which the bug
was reported.

This bug was present in the previous version. The current version was
uploaded precisely to fix the problem reported.

Previous version (7.3-1) had

Depends: libglobus-common0 (>= 15)

Current version (7.3-2) has

Depends: libglobus-common0 (>= 15) | libglobus-common0t64 (>= 15)

I.e. it does not depend only on the old package name, but on either the
new or the old. The package is therefore not blocking the t64
transition.

    Mattias

sön 2024-03-31 klockan 17:41 +0200 skrev Sebastian Ramacher:
> Source: globus-gram-job-manager-scripts
> Version: 7.3-2
> Severity: serious
> X-Debbugs-Cc: sramac...@debian.org
> 
> globus-gram-job-manager-scripts builds an Architecture: all packages
> depending on a library package involved in the time_t 64 transition.
> This dependency needs to be updated.
> 
> Cheers
> --
> Sebastian Ramacher
> 
> VARNING: Klicka inte på länkar och öppna inte bilagor om du inte
> känner igen avsändaren och vet att innehållet är säkert.
> CAUTION: Do not click on links or open attachments unless you
> recognise the sender and know the content is safe.



signature.asc
Description: This is a digitally signed message part

Bug#1068133: globus-gram-audit: arch:all package depends on pre-t64 library

Control: found 1068133 5.1-2
Control: notfound 1068133 5.1-3

The bug reported here is already fixed in the version for which the bug
was reported.

This bug was present in the previous version. The current version was
uploaded precisely to fix the problem reported.

Previous version (5.1-2) had

Depends: libglobus-common0 (>= 15)

Current version (5.1-3) has

Depends: libglobus-common0 (>= 15) | libglobus-common0t64 (>= 15)

I.e. it does not depend only on the old package name, but on either the
new or the old. The package is therefore not blocking the t64
transition.

    Mattias

sön 2024-03-31 klockan 17:39 +0200 skrev Sebastian Ramacher:
> Source: globus-gram-audit
> Version: 5.1-3
> Severity: serious
> X-Debbugs-Cc: sramac...@debian.org
> 
> globus-gram-audit builds an Architecture: all packages depending on a
> library package involved in the time_t 64 transition. This dependency
> needs to be updated.
> 
> Cheers
> --
> Sebastian Ramacher
> 
> VARNING: Klicka inte på länkar och öppna inte bilagor om du inte
> känner igen avsändaren och vet att innehållet är säkert.
> CAUTION: Do not click on links or open attachments unless you
> recognise the sender and know the content is safe.



signature.asc
Description: This is a digitally signed message part

Bug#1068133: globus-gram-audit: arch:all package depends on pre-t64 library

Control: found 1068133 5.1-2
Control: notfound 1068133 5.1-3

The bug reported here is already fixed in the version for which the bug
was reported.

This bug was present in the previous version. The current version was
uploaded precisely to fix the problem reported.

Previous version (5.1-2) had

Depends: libglobus-common0 (>= 15)

Current version (5.1-3) has

Depends: libglobus-common0 (>= 15) | libglobus-common0t64 (>= 15)

I.e. it does not depend only on the old package name, but on either the
new or the old. The package is therefore not blocking the t64
transition.

    Mattias

sön 2024-03-31 klockan 17:39 +0200 skrev Sebastian Ramacher:
> Source: globus-gram-audit
> Version: 5.1-3
> Severity: serious
> X-Debbugs-Cc: sramac...@debian.org
> 
> globus-gram-audit builds an Architecture: all packages depending on a
> library package involved in the time_t 64 transition. This dependency
> needs to be updated.
> 
> Cheers
> --
> Sebastian Ramacher
> 
> VARNING: Klicka inte på länkar och öppna inte bilagor om du inte
> känner igen avsändaren och vet att innehållet är säkert.
> CAUTION: Do not click on links or open attachments unless you
> recognise the sender and know the content is safe.



signature.asc
Description: This is a digitally signed message part

[jira] [Commented] (SCM-1022) jgit push failure is not failing the build

2024-04-04 Thread Mattias Andersson (Jira)



[ 
https://issues.apache.org/jira/browse/SCM-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833892#comment-17833892
 ] 

Mattias Andersson commented on SCM-1022:


[~michael-o] we created the PR above. Any feedback would be appreciated.

> jgit push failure is not failing the build
> --
>
> Key: SCM-1022
> URL: https://issues.apache.org/jira/browse/SCM-1022
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-jgit
>Affects Versions: 2.0.1
>Reporter: Mattias Andersson
>Priority: Major
>
> If the push command fails, the maven build does not fail. This means binaries 
> are deployed, but the remote repo is not updated. The issue seems related to 
> SCM-854. 
> We use Gerrit and have the merge strategy set to "fast forward only". If 
> someone pushes a commit during the release job, only an INFO message is 
> logged, but the maven build is successful. 
> The same use case with the maven-scm-provider-gitexe (the default) fails the 
> build as expected (git push returns a non-zero exit code)
> {code:java}
> 10:28:03  [INFO] commit done: [maven-release-plugin] prepare release 2.15.0
> 10:28:03  [INFO] push changes to remote... refs/heads/master:refs/heads/master
> 10:28:03  [INFO] fetch url: ssh://xxx@xxx
> 10:28:03  [INFO] push url: ssh://xxx@xxx
> 10:28:03  [INFO] getOrCreateProvider(EdDSA) created instance of 
> net.i2p.crypto.eddsa.EdDSASecurityProvider
> 10:28:03  [INFO] No detected/configured IoServiceFactoryFactory using 
> Nio2ServiceFactoryFactory
> 10:28:04  [INFO] REJECTED_NONFASTFORWARD - 
> RemoteRefUpdate[remoteName=refs/heads/master, REJECTED_NONFASTFORWARD, 
> 1eee06203068576ddcaae4eefe0ea15a52fb49ba...3102c82c6b62d4e86c75194569c2574ac722b6dd,
>  srcRef=refs/heads/master, message=null]
> 10:28:04  [INFO] 12/17 prepare:scm-tag
> 10:28:04  [INFO] Tagging release with the label 2.15.0...
> 10:28:04  [INFO] push tag [2.15.0] to remote...
> 10:28:04  [INFO] fetch url: ssh://xxx@xxx
> 10:28:04  [INFO] push url: ssh://xxx@xxx
> 10:28:05  [INFO] OK - RemoteRefUpdate[remoteName=refs/tags/2.15.0, OK, 
> ...968d97de8331ce19d43c719e870890def5ee65d9,
>  fastForward, srcRef=refs/tags/2.15.0, message=null]{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[DFRI-listan] DFRI Styrelsemöte 3 april (OBS: idag onsdag)

2024-04-03 Thread Mattias Axell


Hej!

Sen annonsering här om styrelsemöte ikväll 18:00: 
https://www.dfri.se/styrelsemote-3-april/


Bland annat om ChatControl.

Mvh,
Mattias
--
DFRI.se
Mastodon: https://mastodon.social/@dfri
___
Listan mailing list -- listan@lists.dfri.se
To unsubscribe send an email to listan-le...@lists.dfri.se

Re: [Lazarus] Project.pp

2024-04-03 Thread Mattias Gaertner via lazarus




On 03.04.24 15:28, Gabriele Cappelletto via lazarus wrote:


Il 03/04/24 15:26, Gabriele Cappelletto via lazarus ha scritto:


HI,
I had a package that compiled well with Lazarus 2.2.4 (I used that 
one). Then I switched to 3.2 and it doesn't work anymore.
Exactly it stops because it cannot find the file contained in 
lazarus/ide/Project.pp. What package should I include? And why did it 
work fine in Lazarus 2.2.4 (and also 2.2.6)?


exactly the uses is this

uses
  Classi, SysUtils, Controlli , Forms, Dialogs,
  LazIDEIntf, ProjectIntf, FormEditingIntf, Project, ModeMatrixOpts;





uses
   Classes, SysUtils, Controls, Forms, Dialogs,
   LazIDEIntf, ProjectIntf, FormEditingIntf, Project, ModeMatrixOpts;


Is this the uses section of one of your package units?
Does your package trying to access the IDE unit "project" directly 
instead of the ProjectIntf?


Mattias
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[jira] [Commented] (SCM-1022) jgit push failure is not failing the build

2024-04-03 Thread Mattias Andersson (Jira)



[ 
https://issues.apache.org/jira/browse/SCM-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833532#comment-17833532
 ] 

Mattias Andersson commented on SCM-1022:


The problem seems to be that the return value from JGitUtils.push is ignored in:
{noformat}
org.apache.maven.scm.provider.git.jgit.command.checkin.JGitCheckInCommand#executeCheckInCommand{noformat}
We could try to provide a PR if that would be interesting?

> jgit push failure is not failing the build
> --
>
> Key: SCM-1022
> URL: https://issues.apache.org/jira/browse/SCM-1022
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-jgit
>Affects Versions: 2.0.1
>Reporter: Mattias Andersson
>Priority: Major
>
> If the push command fails, the maven build does not fail. This means binaries 
> are deployed, but the remote repo is not updated. The issue seems related to 
> SCM-854. 
> We use Gerrit and have the merge strategy set to "fast forward only". If 
> someone pushes a commit during the release job, only an INFO message is 
> logged, but the maven build is successful. 
> The same use case with the maven-scm-provider-gitexe (the default) fails the 
> build as expected (git push returns a non-zero exit code)
> {code:java}
> 10:28:03  [INFO] commit done: [maven-release-plugin] prepare release 2.15.0
> 10:28:03  [INFO] push changes to remote... refs/heads/master:refs/heads/master
> 10:28:03  [INFO] fetch url: ssh://xxx@xxx
> 10:28:03  [INFO] push url: ssh://xxx@xxx
> 10:28:03  [INFO] getOrCreateProvider(EdDSA) created instance of 
> net.i2p.crypto.eddsa.EdDSASecurityProvider
> 10:28:03  [INFO] No detected/configured IoServiceFactoryFactory using 
> Nio2ServiceFactoryFactory
> 10:28:04  [INFO] REJECTED_NONFASTFORWARD - 
> RemoteRefUpdate[remoteName=refs/heads/master, REJECTED_NONFASTFORWARD, 
> 1eee06203068576ddcaae4eefe0ea15a52fb49ba...3102c82c6b62d4e86c75194569c2574ac722b6dd,
>  srcRef=refs/heads/master, message=null]
> 10:28:04  [INFO] 12/17 prepare:scm-tag
> 10:28:04  [INFO] Tagging release with the label 2.15.0...
> 10:28:04  [INFO] push tag [2.15.0] to remote...
> 10:28:04  [INFO] fetch url: ssh://xxx@xxx
> 10:28:04  [INFO] push url: ssh://xxx@xxx
> 10:28:05  [INFO] OK - RemoteRefUpdate[remoteName=refs/tags/2.15.0, OK, 
> ...968d97de8331ce19d43c719e870890def5ee65d9,
>  fastForward, srcRef=refs/tags/2.15.0, message=null]{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (SCM-1022) jgit push failure is not failing the build

2024-04-03 Thread Mattias Andersson (Jira)

Mattias Andersson created SCM-1022:
--

 Summary: jgit push failure is not failing the build
 Key: SCM-1022
 URL: https://issues.apache.org/jira/browse/SCM-1022
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-jgit
Affects Versions: 2.0.1
Reporter: Mattias Andersson


If the push command fails, the maven build does not fail. This means binaries 
are deployed, but the remote repo is not updated. The issue seems related to 
SCM-854. 

We use Gerrit and have the merge strategy set to "fast forward only". If 
someone pushes a commit during the release job, only an INFO message is logged, 
but the maven build is successful. 

The same use case with the maven-scm-provider-gitexe (the default) fails the 
build as expected (git push returns a non-zero exit code)
{code:java}
10:28:03  [INFO] commit done: [maven-release-plugin] prepare release 2.15.0
10:28:03  [INFO] push changes to remote... refs/heads/master:refs/heads/master
10:28:03  [INFO] fetch url: ssh://xxx@xxx
10:28:03  [INFO] push url: ssh://xxx@xxx
10:28:03  [INFO] getOrCreateProvider(EdDSA) created instance of 
net.i2p.crypto.eddsa.EdDSASecurityProvider
10:28:03  [INFO] No detected/configured IoServiceFactoryFactory using 
Nio2ServiceFactoryFactory
10:28:04  [INFO] REJECTED_NONFASTFORWARD - 
RemoteRefUpdate[remoteName=refs/heads/master, REJECTED_NONFASTFORWARD, 
1eee06203068576ddcaae4eefe0ea15a52fb49ba...3102c82c6b62d4e86c75194569c2574ac722b6dd,
 srcRef=refs/heads/master, message=null]
10:28:04  [INFO] 12/17 prepare:scm-tag
10:28:04  [INFO] Tagging release with the label 2.15.0...
10:28:04  [INFO] push tag [2.15.0] to remote...
10:28:04  [INFO] fetch url: ssh://xxx@xxx
10:28:04  [INFO] push url: ssh://xxx@xxx
10:28:05  [INFO] OK - RemoteRefUpdate[remoteName=refs/tags/2.15.0, OK, 
...968d97de8331ce19d43c719e870890def5ee65d9,
 fastForward, srcRef=refs/tags/2.15.0, message=null]{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Bug#1068076: libssh2: FTBFS on hurd-any

source: libssh2
version: 1.11.0-1
severity: important

The package fails to build on hurd due to the use of MAXPATHEN:

session_fixture.c:231:36: error: ‘MAXPATHLEN’ undeclared (first use in
this function)
  231 | static char filepath[NUMPATHS][MAXPATHLEN];
  |^~

PATH_MAX and MAXPATHLEN are on purpose not defined on hurd.

Mattias

PS. This currently blocks all packages that depend on libssh2 to be
rebuilt for the lngoing  64 bit time_t transition.



signature.asc
Description: This is a digitally signed message part

Bug#1068073: Hardcoded dependency on liblcmaps0

source: lcmaps-plugins-verify-proxy
version: 1.5.10-2
severity: serious

During the 64 bit time_t transition the package name liblcmaps0 was
changed to liblcmaps0t64. The old name is still provided by the new
package for architectures where this transition did not cause an ABI
break, but not for architectures like armel and armhf, where these
hardcoded dependency on the old package name are now not satisfiable.

Please change these to use either the new name or to depend on either
the old or the new name (liblcmaps0 | liblcmaps0t64).

Package: lcmaps-plugins-verify-proxy
Depends: ${shlibs:Depends}, ${misc:Depends}, liblcmaps0

Mattias



signature.asc
Description: This is a digitally signed message part

Bug#1068073: Hardcoded dependency on liblcmaps0

source: lcmaps-plugins-verify-proxy
version: 1.5.10-2
severity: serious

During the 64 bit time_t transition the package name liblcmaps0 was
changed to liblcmaps0t64. The old name is still provided by the new
package for architectures where this transition did not cause an ABI
break, but not for architectures like armel and armhf, where these
hardcoded dependency on the old package name are now not satisfiable.

Please change these to use either the new name or to depend on either
the old or the new name (liblcmaps0 | liblcmaps0t64).

Package: lcmaps-plugins-verify-proxy
Depends: ${shlibs:Depends}, ${misc:Depends}, liblcmaps0

Mattias



signature.asc
Description: This is a digitally signed message part

Bug#1068072: Hardcoded dependency on liblcmaps0

source: lcmaps-plugins-basic
version: 1.7.1-1
severity: serious

During the 64 bit time_t transition the package name liblcmaps0 was
changed to liblcmaps0t64. The old name is still provided by the new
package for architectures where this transition did not cause an ABI
break, but not for architectures like armel and armhf, where these
hardcoded dependency on the old package name are now not satisfiable.

Please change these to use either the new name or to depend on either
the old or the new name (liblcmaps0 | liblcmaps0t64).

Package: lcmaps-plugins-basic-dummy
Depends: ${misc:Depends}, ${shlibs:Depends}, liblcmaps0

Package: lcmaps-plugins-basic-localaccount
Depends: ${misc:Depends}, ${shlibs:Depends}, liblcmaps0

Package: lcmaps-plugins-basic-poolaccount
Depends: ${misc:Depends}, ${shlibs:Depends}, liblcmaps0

Package: lcmaps-plugins-basic-posixenf
Depends: ${misc:Depends},  ${shlibs:Depends}, liblcmaps0

Package: lcmaps-plugins-basic-ldap
Depends: ${misc:Depends},  ${shlibs:Depends}, liblcmaps0

Mattias



signature.asc
Description: This is a digitally signed message part

Bug#1068072: Hardcoded dependency on liblcmaps0

source: lcmaps-plugins-basic
version: 1.7.1-1
severity: serious

During the 64 bit time_t transition the package name liblcmaps0 was
changed to liblcmaps0t64. The old name is still provided by the new
package for architectures where this transition did not cause an ABI
break, but not for architectures like armel and armhf, where these
hardcoded dependency on the old package name are now not satisfiable.

Please change these to use either the new name or to depend on either
the old or the new name (liblcmaps0 | liblcmaps0t64).

Package: lcmaps-plugins-basic-dummy
Depends: ${misc:Depends}, ${shlibs:Depends}, liblcmaps0

Package: lcmaps-plugins-basic-localaccount
Depends: ${misc:Depends}, ${shlibs:Depends}, liblcmaps0

Package: lcmaps-plugins-basic-poolaccount
Depends: ${misc:Depends}, ${shlibs:Depends}, liblcmaps0

Package: lcmaps-plugins-basic-posixenf
Depends: ${misc:Depends},  ${shlibs:Depends}, liblcmaps0

Package: lcmaps-plugins-basic-ldap
Depends: ${misc:Depends},  ${shlibs:Depends}, liblcmaps0

Mattias



signature.asc
Description: This is a digitally signed message part

Bug#1068071: Hardcoded dependency on liblcmaps0

source: lcmaps-plugins-jobrep
version: 1.5.6-1.1
severity: serious

During the 64 bit time_t transition the package name liblcmaps0 was
changed to liblcmaps0t64. The old name is still provided by the new
package for architectures where this transition did not cause an ABI
break, but not for architectures like armel and armhf, where these
hardcoded dependency on the old package name are now not satisfiable.

Please change these to use either the new name or to depend on either
the old or the new name (liblcmaps0 | liblcmaps0t64).

Package: lcmaps-plugins-jobrep
Depends: ${shlibs:Depends}, ${misc:Depends}, liblcmaps0

Mattias



signature.asc
Description: This is a digitally signed message part

Bug#1068071: Hardcoded dependency on liblcmaps0

source: lcmaps-plugins-jobrep
version: 1.5.6-1.1
severity: serious

During the 64 bit time_t transition the package name liblcmaps0 was
changed to liblcmaps0t64. The old name is still provided by the new
package for architectures where this transition did not cause an ABI
break, but not for architectures like armel and armhf, where these
hardcoded dependency on the old package name are now not satisfiable.

Please change these to use either the new name or to depend on either
the old or the new name (liblcmaps0 | liblcmaps0t64).

Package: lcmaps-plugins-jobrep
Depends: ${shlibs:Depends}, ${misc:Depends}, liblcmaps0

Mattias



signature.asc
Description: This is a digitally signed message part

Bug#1068070: Hardcoded dependency on liblcmaps0

source: lcmaps-plugins-voms
version: 1.7.1-1
severity: serious

During the 64 bit time_t transition the package name liblcmaps0 was
changed to liblcmaps0t64. The old name is still provided by the new
package for architectures where this transition did not cause an ABI
break, but not for architectures like armel and armhf, where these
hardcoded dependency on the old package name are now not satisfiable.

Please change these to use either the new name or to depend on either
the old or the new name (liblcmaps0 | liblcmaps0t64).

Package: lcmaps-plugins-voms
Depends: ${shlibs:Depends}, ${misc:Depends},
 liblcmaps0 (>= 1.5.0)

    Mattias



signature.asc
Description: This is a digitally signed message part

Bug#1068070: Hardcoded dependency on liblcmaps0

source: lcmaps-plugins-voms
version: 1.7.1-1
severity: serious

During the 64 bit time_t transition the package name liblcmaps0 was
changed to liblcmaps0t64. The old name is still provided by the new
package for architectures where this transition did not cause an ABI
break, but not for architectures like armel and armhf, where these
hardcoded dependency on the old package name are now not satisfiable.

Please change these to use either the new name or to depend on either
the old or the new name (liblcmaps0 | liblcmaps0t64).

Package: lcmaps-plugins-voms
Depends: ${shlibs:Depends}, ${misc:Depends},
 liblcmaps0 (>= 1.5.0)

    Mattias



signature.asc
Description: This is a digitally signed message part

Re: [PATCH v8 0/5] Support message-based DMA in vfio-user server

2024-03-28 Thread Mattias Nissler

Stefan, to the best of my knowledge this is fully reviewed and ready
to go in - can you kindly pick it up or advise in case there's
something I missed? Thanks!

On Mon, Mar 4, 2024 at 11:25 AM Peter Xu  wrote:
>
> On Mon, Mar 04, 2024 at 02:05:49AM -0800, Mattias Nissler wrote:
> > This series adds basic support for message-based DMA in qemu's vfio-user
> > server. This is useful for cases where the client does not provide file
> > descriptors for accessing system memory via memory mappings. My motivating 
> > use
> > case is to hook up device models as PCIe endpoints to a hardware design. 
> > This
> > works by bridging the PCIe transaction layer to vfio-user, and the endpoint
> > does not access memory directly, but sends memory requests TLPs to the 
> > hardware
> > design in order to perform DMA.
> >
> > Note that more work is needed to make message-based DMA work well: qemu
> > currently breaks down DMA accesses into chunks of size 8 bytes at maximum, 
> > each
> > of which will be handled in a separate vfio-user DMA request message. This 
> > is
> > quite terrible for large DMA accesses, such as when nvme reads and writes
> > page-sized blocks for example. Thus, I would like to improve qemu to be 
> > able to
> > perform larger accesses, at least for indirect memory regions. I have 
> > something
> > working locally, but since this will likely result in more involved surgery 
> > and
> > discussion, I am leaving this to be addressed in a separate patch.
>
> No objection from my side memory-wise.  It'll be good to get some words
> from Paolo if possible.
>
> Copy Peter Maydell due to the other relevant discussion.
>
> https://lore.kernel.org/qemu-devel/20240228125939.56925-1-heinrich.schucha...@canonical.com/
>
> --
> Peter Xu
>

Re: [blind-gamers] manamon2 solfier cave?

2024-03-25 Thread mattias

fighting

> 25 mars 2024 kl. 21:37 skrev Chris Shook via groups.io 
> :
> 
> A Manya? Which Manamon is that?
> 
> On Monday, March 25, 2024 at 03:50:12 PM EDT, mattias  <mailto:mjonsson1...@gmail.com>> wrote:
> 
> 
> I found a manya in that cave
> But i totaly forgot where that Cave was located
> Can anyone remind me?
>  
> Skickades från E-post <https://go.microsoft.com/fwlink/?LinkId=550986> för 
> Windows
>  
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#127238): https://groups.io/g/blind-gamers/message/127238
Mute This Topic: https://groups.io/mt/105145507/21656
Group Owner: blind-gamers+ow...@groups.io
Unsubscribe: 
https://groups.io/g/blind-gamers/leave/607459/21656/1071380848/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[blind-gamers] manamon2 solfier cave?

2024-03-25 Thread mattias

I found a manya in that caveBut i totaly forgot where that Cave was locatedCan anyone remind me? Skickades från E-post för Windows 


_._,_._,_



Groups.io Links:


  
You receive all messages sent to this group.
  
  



View/Reply Online (#127236) |


  Reply To Group
  

|

  Mute This Topic


| New Topic






Your Subscription |
Contact Group Owner |

Unsubscribe

 [arch...@mail-archive.com]
_._,_._,_

Re: [fpc-devel] Failing Lazarus Codetools Pas2JS-related tests - again

2024-03-19 Thread Mattias Gaertner via fpc-devel





On 19.03.24 14:58, Maxim Ganetsky via fpc-devel wrote:

[...]
#7 944.7 fpmake.pp(228,5) Error: Identifier not found "T"


Ah, you are using fpc 3.3.1 to compile it.

Fixed.

But I get strange linker errors compiling webidl2pas:

(9015) Linking bin/x86_64-linux/webidl2pas
/usr/bin/ld.bfd: 
/path/compiler/utils/pas2js/units/x86_64-linux/webidl2pas.o:(.fpc.n_links+0x50): 
undefined reference to `DEBUGSTART_$CUSTAPP'
/usr/bin/ld.bfd: 
/path/compiler/utils/pas2js/units/x86_64-linux/webidl2pas.o:(.fpc.n_links+0x58): 
undefined reference to `DEBUGEND_$CUSTAPP'


It compiles with the ppu files of fpc 3.3.1 and 3.2.2 tough, but not 
with the sources ...


Mattias
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Failing Lazarus Codetools Pas2JS-related tests - again

2024-03-19 Thread Mattias Gaertner via fpc-devel





On 18.03.24 20:29, Michael Van Canneyt via fpc-devel wrote:

[...]

#7 1429.0 -Fu$CfgDir/../lib/fpc/3.3.1/pas2js/*/*/namespaced
||
#7 1429.0 -Fi$CfgDir/../lib/fpc/3.3.1/pas2js/*/*/src


This seems wrong to me, but Mattias will need to look at this.


I changed the fpmake.pp. Please test.

Mattias

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Failing Lazarus Codetools Pas2JS-related tests - again

2024-03-18 Thread Mattias Gaertner via fpc-devel





On 18.03.24 18:43, Maxim Ganetsky via fpc-devel wrote:

[...]
After recent update of FPC 3.3.1 (and Pas2JS) in Lazarus CI several 
Codetools tests related to Pas2JS started failing again:


TTestPas2js.TestPas2js_ReadSettings: pas2js system unit not found
TTestPas2js.TestPas2js_FindDeclaration: pas2js system unit not found
TTestPas2js.TestPas2js_FindDeclaration_AWait: pas2js system unit not found

They worked fine with FPC 3.3.1 from the end of December.

Contents of Pas2JS configuration files follow:

[...]
#7 1429.0 #else
||
#7 1429.0 -Fu$CfgDir/../lib/fpc/3.3.1/pas2js/*/*/src


This should be enough
-Fu$CfgDir/../lib/fpc/3.3.1/pas2js/packages/*/src


[...]

Can you compile a simple Helloworld?

begin
  writeln('Hi');
end.

?

If this works, you might try removing the 
components/codetools/tests/codetools.config, so codetools rebuild the cache.



Mattias
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [dev] [ubase] compile using musl

2024-03-15 Thread Mattias Andrée

On Fri, 15 Mar 2024 16:22:19 -0300
Brian Mayer  wrote:

> Hi, I'm Brian, I'm trying to compile ubase using musl as libc on
> buildroot. I use a Pinebook Pro, so aarch64 is my arch.
> 
> By just running make I get this error:
> 
> /home/blmayer/git/distro/buildroot/output/host/bin/aarch64-buildroot-linux-musl-gcc
> -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -O2
> -g0  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
> -o df.o -c df.c
> dd.c: In function 'copy_splice':
> dd.c:179:21: warning: implicit declaration of function 'splice'
> [-Wimplicit-function-declaration]
>  179 | r = splice(ifd, NULL, p[1], NULL, n, SPLICE_F_MORE);
>  | ^~
> /home/blmayer/git/distro/buildroot/output/host/bin/aarch64-buildroot-linux-musl-gcc
> -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -O2
> -g0  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
> -o dmesg.o -c dmesg.c
> dd.c:179:54: error: 'SPLICE_F_MORE' undeclared (first use in this function)
>  179 | r = splice(ifd, NULL, p[1], NULL, n, SPLICE_F_MORE);
>  |  ^
> dd.c:179:54: note: each undeclared identifier is reported only once
> for each function it appears in
> /home/blmayer/git/distro/buildroot/output/host/bin/aarch64-buildroot-linux-musl-gcc
> -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -O2
> -g0  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
> -o eject.o -c eject.c
> make[1]: *** [Makefile:164: dd.o] Error 1
> 
> My guess is that glibc provides that function by musl doesn't. So as
> my system is using musl that function is not found. Can I get some
> help?
> 
> Thanks,
> Brian
> 

Add -D_GNU_SOURCE

Re: [dev] [sbase] Defining scope of sbase and ubase

2024-03-09 Thread Mattias Andrée

On Sat, 09 Mar 2024 17:28:49 +0100
Elie Le Vaillant  wrote:

> Страхиња Радић  wrote:
> > Compiling all programs into one binary is currently an option, and IMHO it 
> > should remain an option.  
> 
> I fully agree. However, the single binary situation should be improved.
> 
> > Great, combine the two versions of libutil into a single, separate
> > libutil repository  
> 
> I'm not sure whether or not this is a good idea, because it makes
> sbase and ubase dependant upon a separate repository, which needs to
> be present in the parent directory for it to build. It'd also make
> sbase development cumbersome, because we very frequently change
> libutil when we change sbase. Both are developed as one single
> project, and patches reflect this. libutil should not be isolated I
> think.
> 
> > then have a directory hierarchy like this:
> > 
> > corebox
> > ├──sbase (portable only)  \
> > ├──ubase (nonportable) depend on libutil.so and/or libutil.a
> > ├──xbase (non-POSIX)  /
> > └──libutil (option to produce .so and/or .a)  
> 
> ubase is not only nonportable, it is _linux-specific_. It is also
> non-POSIX. I think ubase should be renamed to reflect this. The
> distinction between POSIX/non-POSIX is, I think, not very useful. As

There are also multiple standards, not just POSIX. For example
tar, true, false are not POSIX (tar was removed from POSIX, and
true and false are defined only as shell built-in in POSIX), but they
are defined in LSB which a propular, but it's a Linux specific standard.
Most of POSIX but not all of POSIX is also defined by LSB.

> Mattias said, pure POSIX is quite cumbersome, and not very descriptive
> as of what you can expect from it. sh and vi are POSIX, but out-of-scope
> for sbase (from the TODO), whereas sponge is crucial for sbase (it
> allows simpler implementation of -i for sed, which _is_ POSIX, or the
> -o flag for sort (POSIX too)) and would thus be excluded from sbase
> and put into xbase.

sed -i is not POSIX.

> 
> The solution Mattias proposed (having one big repository, a portable
> subdir, a linux (and maybe others in the future, like openbsd) subdir
> and a Makefile which includes more descriptive sets than POSIX/non-POSIX
> (well, it _can_ be used, but it is not enough)) is I think the best to
> fix the problem of libutil duplication/drifting away of versions. It
> also allows a broader scope without impeding on the goals of sucklessness.
> 
> One supplementary question, more in line with the original question asked
> by Roberto E. Vargas Caballero, is: would awk and sh be out-of-scope?
> Should we rather try to implement extensions to awk, or follow the 
> specification
> as strictly possible? Should we implement POSIX sh, or some other shell, such 
> as rc?
> Or is it out-of-scope for us to implement a full-blown shell? I really am
> not sure.

I don't think there is any reason that sbase should implement
all of the standard utilities you need, I think it should only
be the small tools that you can reasonably write in one file.
Large and complicated programs like sh should be it's own project.

> 
> Regards,
> Elie Le Vaillant
>

Re: [dev] [sbase] Defining scope of sbase and ubase

2024-03-09 Thread Mattias Andrée

On Sat, 9 Mar 2024 14:53:07 +0100
Страхиња Радић  wrote:

> On 24/03/09 12:59AM, Mattias Andrée wrote:
> > I agree, a single repo (or alternatively making libutil it's own repo) is
> > necessary if we want one binary, and I think we do.  
> 
> Compiling all programs into one binary is currently an option, and IMHO it 
> should remain an option. In my own toy distro[1] based on Musl-LFS and using 
> sbase and ubase I compile all programs from {s,u}base separately.
> 
> The reasons why I consider that beneficial over a single executable include, 
> but are not limited to:
> 
> - Easier to maintain: if an administrator decides a utility is unnecessary or 
>   shouldn't be available, it comes down to rm-ing the file vs recompilation 
> of 
>   the entire *box.
> 
> - More robust: in case of disk corruption, all of the utilities are 
> unavailable 
>   vs only those affected.
> 
> - Fine-grained control: separate programs can be compiled using specific
>   compilation options (eg. -g -O0) vs all of the programs sharing compilation 
>   options.
> 
> etc.
> 
> 
> > Even if submodules was possible, I do not think they are a good solution.  
> 
> What makes the git submodules not possible?

I haven't actually checked, but it safe to assume that if it is not
already a problem it very well could become one (and it probably is).
If the two libutil implementations have functions with the same names
they cannot both be linked into the same binary. A "solution" would
be to use weak linkage, but then you can run into problems when the
functions that share name do not share behaviour (e.g. have different
prototype or return type).

> 
> 
> > Using submodules is unpleasant and pointless since all could is under our
> > control. I think submodules should only be used for code that you do not
> > have control over but need the source code for. Either you have separate
> > repos and have normal compile time dependencies (require that the libraries
> > are installed) or you put everything in one place, one repo.  
> 
> Everything in the quoted part seems personal preference. Git submodules offer 
> a 
> way to easily establish a hierarchy of git repositories while keeping them as 
> separate "units".

Of course these are personal preferences. There aren't any technical problems
using git submodules assuming you can put everything in the same repo.

> 
> So the libutil differs in sbase and ubase. Great, combine the two versions of 
> libutil into a single, separate libutil repository, then have a directory 
> hierarchy like this:
> 
> corebox
> ├──sbase (portable only)  \
> ├──ubase (nonportable) depend on libutil.so and/or libutil.a
> ├──xbase (non-POSIX)  /
> └──libutil (option to produce .so and/or .a)
> 
> 
> 
> [1]: https://strahinja.srht.site/galeb
>

Re: [dev] [sbase] Defining scope of sbase and ubase

2024-03-09 Thread Mattias Andrée

On Sat, 09 Mar 2024 12:10:28 +0100
Eolien55  wrote:

> Mattias Andrée  wrote:
> > I think there should be one directory called "portable" containing only 
> > tools
> > from sbase, and one directory called "linux" containing the tools from ubase
> > and maybe even symlinks to the tools in "portable". This structure would 
> > allow
> > us to add implementations for other operating systems as well. If we add
> > symlinks to the tools in "portable" to "linux", each directory could have
> > it's own makefile. But I'm not sure this is preferable over a single 
> > Makefile
> > in the root directory.  
> 
> This is a great idea! Your mail on the other branch is a great idea too.
> I think we should have platform-specific libutil for unportable functions
> in ubase's libutil (so, linux/libutil, openbsd/libutil and so on, if we
> do actually add implementations for other OSes), and a top-level libutil
> too.
> 
> This could maybe allow adding platform-agnostic implementations of some utils
> (not all because some APIs are so different that it requires full rewrites,
> but maybe some, such as clear, stty, tput, or dd maybe).
> 
> I will start hacking on it, and will post the git repository for it
> when it builds correctly.
> 
> I'm not sure how you combine two repositories into one while keeping the
> history though.

git init .

git pull git://git.suckless.org/sbase
git branch -M master sbase
mkdir sbase
mv * .gitignore sbase
git add .
git commit -m 'Move all of sbase into its own directory'

git checkout --orphan master
git rm -rf .

git pull git://git.suckless.org/ubase
git branch -M master ubase
mkdir ubase
mv * .gitignore ubase
git add .
git commit -m 'Move all of ubase into its own directory'

git checkout --orphan master
git rm -rf .
git pull --allow-unrelated-histories . sbase
git pull --allow-unrelated-histories . ubase


> 
> Regards,
> Elie Le Vaillant
>

Re: [dev] [sbase] Defining scope of sbase and ubase

2024-03-08 Thread Mattias Andrée

On Fri, 08 Mar 2024 23:33:12 +0100
Eolien55  wrote:

> Страхиња Радић  wrote:
> > The problem of having separate *box executables could be solved by creating 
> > an 
> > "umbrella" *box project, perhaps having sbase, ubase and 
> > [insert_letter]base as 
> > git submodules, and deciding what to build based on the contents of 
> > config.mk.  
> 
> The problem is that sbase and ubase each include a version of libutil, whith 
> some
> functions which are the same, and some other wich serve the same function but
> vary in implementation due to version history.
> 
> git submodules are kinda meh I think for this problem, because it wouldn't 
> change
> the problem of source code duplication (and of versions drifting apart) 
> between
> the 2 projects, as libutil is part of both sbase and ubase trees (not mereley 
> the
> umbrella-box project).
> 
> I believe we should put what are currently sbase and ubsase in a single git 
> repository,
> sharing all that is portably sharable, but still separating utilities that 
> are portable
> from linux-specific ones.
> 
> I think sbase and ubase should try to provide useful, well-implemented, 
> suckless
> utilities. If we want POSIX utilities, let's add them! But I don't think we 
> should
> restrain us from doing that. sbase's sponge and cols is so useful I'm 
> constantly
> using them, even though I normally use busybox.
> 
> Regards,
> Elie Le Vaillant
> 

I agree, a single repo (or alternatively making libutil it's own repo) is
necessary if we want one binary, and I think we do.

Even if submodules was possible, I do not think they are a good solution.
Using submodules is unpleasant and pointless since all could is under our
control. I think submodules should only be used for code that you do not
have control over but need the source code for. Either you have separate
repos and have normal compile time dependencies (require that the libraries
are installed) or you put everything in one place, one repo.

I see the separation of sbase and ubase into two repositories as basically
equivalent to the a single repo with a sbase directory and a ubase directory,
except better when it comes to tagging new versions, but since there reason
to have separate releases for these, it doesn't really make a difference.
So simply putting sbase and ubase in two different directories in the same
repo, and then put a makefile there to build all of it into one binary would
be step up, of course there would be some linkage problems and making them
share libutil would be the next step up. Of course, it should be possible
to select if you want ubase included in your binary or not, is the point
of the separation in the first place.

I think there should be one directory called "portable" containing only tools
from sbase, and one directory called "linux" containing the tools from ubase
and maybe even symlinks to the tools in "portable". This structure would allow
us to add implementations for other operating systems as well. If we add
symlinks to the tools in "portable" to "linux", each directory could have
it's own makefile. But I'm not sure this is preferable over a single Makefile
in the root directory.

As mentioned in an other branch of this conversation, I think we should
have a base with only the POSIX tools but than have additional optional
tools, which could be group into overlapping categories, as you can select
what you want on your system.

Best regards,
Mattias Andrée

Re: [dev] [sbase] Defining scope of sbase and ubase

2024-03-08 Thread Mattias Andrée

I think we should keep the implementation of each tool as minimal as
possible, but POSIX-complete, and of course common tools such as
install(1) and tar(1). However, actually using a system that is
nothing more than POSIX is very cumbersome. And I think it is a better
solution to implement non-standard tools when possible to address
usability issues, e.g. implementing sponge(1) instead of -i for sed(1).

However, if the system isn't actually intended for be used
interactively via the command line, e.g. on embedded devices
or a service running in a container, there is no for non-standard
tools such as sponge(1), and it ought to be easy to select what
you want on your system. I suggest that tools be group into a
few categories (unless they are organised into separate directories
I see no reason one tool couldn't be in multiple categories).

These categories could for example:
- "posix" for all POSIX tools,
- "lsb" for all LSB tools
- "users" for account management
- "extra" for other common tools
- "common" for "posix", "lsb", "users", and "extra"
- "interative" for tools that only make since of when
  a lot via the terminal
- "all" for every implemented tool

Maybe these should also be subdivided into "portable" and "linux".

The user could then specify the tools to include either by
setting BIN when running make(1) or by saying "yes" or "no" to
each category (of course each category would have a default
option), e.g. POSIX=yes INTERACTIVE=no.

Best regards,
Mattias Andrée


On Fri, 08 Mar 2024 11:36:27 +0100
Elie Le Vaillant  wrote:

> Hi,
> 
> I think one of the main current issues with the current
> organization of sbase's and ubase's code, is that while
> they share parts of code (some parts of libutil are shared),
> they do not actually have it in common. As a result, changes
> to shared parts of libutil in sbase are not reflected in ubase,
> and vice-versa.
> 
> Some parts of ubase's libutil are not portable, so indeed it
> makes sense that they are ubase-specific. But some, such as
> recurse, strtonum, strl*, ealloc, eprinf, and maybe others,
> serve the same exact function as in sbase, but sometimes
> vary in implementation, because they didn't receive the same
> patches.
> 
> So I wonder:
> - Is this a problem that needs fixing? (I think yes)
> - How do we fix it?
> 
> We could sync both periodically, applying whichever patch change
> both *base's libutil to both.
> 
> Another idea could be to have both in the same git repository,
> allowing libutil (and possibily more code, like libutf if we
> ever need to) to be shared between them both without syncing
> them back and forth. My idea would be something like this:
> 
> sbase/
>   portable/
> ls.c
> cols.c
> ...
>   unportable/
> ps.c
> kill.c
> ...
>   libutf
>   libutil/
> portable
> unportable
>   Makefile
> 
> This could fix the "multiple -box" problems. This would require
> rewriting some parts of the Makefile (for example, having PORTABLEBIN
> and UNPORTABLEBIN to select whether or not we want the unportable
> utilities; the mkbox script also), and could also provide a solution for
> the "moretools" repo by having it being a separate directory in this
> hypothetical repository.
> 
> Also I'm not sure whether we should keep the goal of being POSIX-compliant.
> ls doesn't columnate, we have (non-standard) cols to do this. sed doesn't
> have the -i flag, we have sponge for this. cron isn't specified by POSIX,
> only crontab is. Maybe toybox roadmap's section on POSIX is relevant:
> https://landley.net/toybox/roadmap.html
> 
> I think we should try and implement a minimal Unix-like userspace,
> and allow ourselves some freedom on what to implement. We already
> do this with sponge and cols. On ubase it is true also, with ctrlaltdel
> for example. I do not see why not do it more.
> 
> Overall I think bringing everything in the same repository, with
> what is now sbase and ubase in separate directories rather than
> separate repositories, would fix both the current situation, and
> allow for a "sextra"/"uextra" directory for supplementary tools.
> 
> Mattias Andrée already proposed this back when he proposed a patch
> for shuf(1):
> > No, we don't really need shuf(1) in sbase, but I think we
> > should have a suckless implementation available, it can be
> > a useful utility. I have a few more utilities I fund useful
> > but I haven't bothered to set up a repository yet. [...]
> > I think it might be a good idea to have sextra for portable
> > utilities and uextra for unportable utilities, if you have
> > any other suggestions I would like to hear them.   
> 
> I think this could fix the current situation, with code on
> different versions split between 2 repositories and ultimately
> 2 -box binaries, and allow a broader scope without impeding the
> goals of minimalness of sbase/ubase.
> 
> Regards,
> Elie Le Vaillant
>

[PATCH v8 1/5] softmmu: Per-AddressSpace bounce buffering

Instead of using a single global bounce buffer, give each AddressSpace
its own bounce buffer. The MapClient callback mechanism moves to
AddressSpace accordingly.

This is in preparation for generalizing bounce buffer handling further
to allow multiple bounce buffers, with a total allocation limit
configured per AddressSpace.

Reviewed-by: Peter Xu 
Tested-by: Jonathan Cameron 
Signed-off-by: Mattias Nissler 
---
 include/exec/cpu-common.h |   2 -
 include/exec/memory.h |  45 -
 system/dma-helpers.c  |   4 +-
 system/memory.c   |   7 +++
 system/physmem.c  | 101 --
 5 files changed, 93 insertions(+), 66 deletions(-)

diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index 9ead1be100..bd6999fa35 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -148,8 +148,6 @@ void *cpu_physical_memory_map(hwaddr addr,
   bool is_write);
 void cpu_physical_memory_unmap(void *buffer, hwaddr len,
bool is_write, hwaddr access_len);
-void cpu_register_map_client(QEMUBH *bh);
-void cpu_unregister_map_client(QEMUBH *bh);
 
 bool cpu_physical_memory_is_io(hwaddr phys_addr);
 
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 8626a355b3..0658846555 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -1106,6 +1106,19 @@ struct MemoryListener {
 QTAILQ_ENTRY(MemoryListener) link_as;
 };
 
+typedef struct AddressSpaceMapClient {
+QEMUBH *bh;
+QLIST_ENTRY(AddressSpaceMapClient) link;
+} AddressSpaceMapClient;
+
+typedef struct {
+MemoryRegion *mr;
+void *buffer;
+hwaddr addr;
+hwaddr len;
+bool in_use;
+} BounceBuffer;
+
 /**
  * struct AddressSpace: describes a mapping of addresses to #MemoryRegion 
objects
  */
@@ -1123,6 +1136,12 @@ struct AddressSpace {
 struct MemoryRegionIoeventfd *ioeventfds;
 QTAILQ_HEAD(, MemoryListener) listeners;
 QTAILQ_ENTRY(AddressSpace) address_spaces_link;
+
+/* Bounce buffer to use for this address space. */
+BounceBuffer bounce;
+/* List of callbacks to invoke when buffers free up */
+QemuMutex map_client_list_lock;
+QLIST_HEAD(, AddressSpaceMapClient) map_client_list;
 };
 
 typedef struct AddressSpaceDispatch AddressSpaceDispatch;
@@ -2926,8 +2945,8 @@ bool address_space_access_valid(AddressSpace *as, hwaddr 
addr, hwaddr len,
  * May return %NULL and set *@plen to zero(0), if resources needed to perform
  * the mapping are exhausted.
  * Use only for reads OR writes - not for read-modify-write operations.
- * Use cpu_register_map_client() to know when retrying the map operation is
- * likely to succeed.
+ * Use address_space_register_map_client() to know when retrying the map
+ * operation is likely to succeed.
  *
  * @as: #AddressSpace to be accessed
  * @addr: address within that address space
@@ -2952,6 +2971,28 @@ void *address_space_map(AddressSpace *as, hwaddr addr,
 void address_space_unmap(AddressSpace *as, void *buffer, hwaddr len,
  bool is_write, hwaddr access_len);
 
+/*
+ * address_space_register_map_client: Register a callback to invoke when
+ * resources for address_space_map() are available again.
+ *
+ * address_space_map may fail when there are not enough resources available,
+ * such as when bounce buffer memory would exceed the limit. The callback can
+ * be used to retry the address_space_map operation. Note that the callback
+ * gets automatically removed after firing.
+ *
+ * @as: #AddressSpace to be accessed
+ * @bh: callback to invoke when address_space_map() retry is appropriate
+ */
+void address_space_register_map_client(AddressSpace *as, QEMUBH *bh);
+
+/*
+ * address_space_unregister_map_client: Unregister a callback that has
+ * previously been registered and not fired yet.
+ *
+ * @as: #AddressSpace to be accessed
+ * @bh: callback to unregister
+ */
+void address_space_unregister_map_client(AddressSpace *as, QEMUBH *bh);
 
 /* Internal functions, part of the implementation of address_space_read.  */
 MemTxResult address_space_read_full(AddressSpace *as, hwaddr addr,
diff --git a/system/dma-helpers.c b/system/dma-helpers.c
index 9b221cf94e..74013308f5 100644
--- a/system/dma-helpers.c
+++ b/system/dma-helpers.c
@@ -169,7 +169,7 @@ static void dma_blk_cb(void *opaque, int ret)
 if (dbs->iov.size == 0) {
 trace_dma_map_wait(dbs);
 dbs->bh = aio_bh_new(ctx, reschedule_dma, dbs);
-cpu_register_map_client(dbs->bh);
+address_space_register_map_client(dbs->sg->as, dbs->bh);
 return;
 }
 
@@ -197,7 +197,7 @@ static void dma_aio_cancel(BlockAIOCB *acb)
 }
 
 if (dbs->bh) {
-cpu_unregister_map_client(dbs->bh);
+address_space_unregister_map_client(dbs->sg->as, dbs->bh);
 qemu_bh_delete(dbs->bh);
 dbs->bh = NULL;
 }
diff --git a/system/memory.c b/system/memor

[PATCH v8 2/5] softmmu: Support concurrent bounce buffers

When DMA memory can't be directly accessed, as is the case when
running the device model in a separate process without shareable DMA
file descriptors, bounce buffering is used.

It is not uncommon for device models to request mapping of several DMA
regions at the same time. Examples include:
 * net devices, e.g. when transmitting a packet that is split across
   several TX descriptors (observed with igb)
 * USB host controllers, when handling a packet with multiple data TRBs
   (observed with xhci)

Previously, qemu only provided a single bounce buffer per AddressSpace
and would fail DMA map requests while the buffer was already in use. In
turn, this would cause DMA failures that ultimately manifest as hardware
errors from the guest perspective.

This change allocates DMA bounce buffers dynamically instead of
supporting only a single buffer. Thus, multiple DMA mappings work
correctly also when RAM can't be mmap()-ed.

The total bounce buffer allocation size is limited individually for each
AddressSpace. The default limit is 4096 bytes, matching the previous
maximum buffer size. A new x-max-bounce-buffer-size parameter is
provided to configure the limit for PCI devices.

Reviewed-by: Peter Xu 
Tested-by: Jonathan Cameron 
Signed-off-by: Mattias Nissler 
---
 hw/pci/pci.c|  8 
 include/exec/memory.h   | 14 +++
 include/hw/pci/pci_device.h |  3 ++
 system/memory.c |  5 ++-
 system/physmem.c| 80 +
 5 files changed, 74 insertions(+), 36 deletions(-)

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 6496d027ca..036b3ff822 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -85,6 +85,8 @@ static Property pci_props[] = {
 QEMU_PCIE_ERR_UNC_MASK_BITNR, true),
 DEFINE_PROP_BIT("x-pcie-ari-nextfn-1", PCIDevice, cap_present,
 QEMU_PCIE_ARI_NEXTFN_1_BITNR, false),
+DEFINE_PROP_SIZE("x-max-bounce-buffer-size", PCIDevice,
+ max_bounce_buffer_size, DEFAULT_MAX_BOUNCE_BUFFER_SIZE),
 DEFINE_PROP_END_OF_LIST()
 };
 
@@ -1203,6 +1205,8 @@ static PCIDevice *do_pci_register_device(PCIDevice 
*pci_dev,
"bus master container", UINT64_MAX);
 address_space_init(_dev->bus_master_as,
_dev->bus_master_container_region, pci_dev->name);
+pci_dev->bus_master_as.max_bounce_buffer_size =
+pci_dev->max_bounce_buffer_size;
 
 if (phase_check(PHASE_MACHINE_READY)) {
 pci_init_bus_master(pci_dev);
@@ -2632,6 +2636,10 @@ static void pci_device_class_init(ObjectClass *klass, 
void *data)
 k->unrealize = pci_qdev_unrealize;
 k->bus_type = TYPE_PCI_BUS;
 device_class_set_props(k, pci_props);
+object_class_property_set_description(
+klass, "x-max-bounce-buffer-size",
+"Maximum buffer size allocated for bounce buffers used for mapped "
+"access to indirect DMA memory");
 }
 
 static void pci_device_class_base_init(ObjectClass *klass, void *data)
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 0658846555..3fe0e2824c 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -,13 +,7 @@ typedef struct AddressSpaceMapClient {
 QLIST_ENTRY(AddressSpaceMapClient) link;
 } AddressSpaceMapClient;
 
-typedef struct {
-MemoryRegion *mr;
-void *buffer;
-hwaddr addr;
-hwaddr len;
-bool in_use;
-} BounceBuffer;
+#define DEFAULT_MAX_BOUNCE_BUFFER_SIZE (4096)
 
 /**
  * struct AddressSpace: describes a mapping of addresses to #MemoryRegion 
objects
@@ -1137,8 +1131,10 @@ struct AddressSpace {
 QTAILQ_HEAD(, MemoryListener) listeners;
 QTAILQ_ENTRY(AddressSpace) address_spaces_link;
 
-/* Bounce buffer to use for this address space. */
-BounceBuffer bounce;
+/* Maximum DMA bounce buffer size used for indirect memory map requests */
+uint64_t max_bounce_buffer_size;
+/* Total size of bounce buffers currently allocated, atomically accessed */
+uint64_t bounce_buffer_size;
 /* List of callbacks to invoke when buffers free up */
 QemuMutex map_client_list_lock;
 QLIST_HEAD(, AddressSpaceMapClient) map_client_list;
diff --git a/include/hw/pci/pci_device.h b/include/hw/pci/pci_device.h
index d3dd0f64b2..f4027c5379 100644
--- a/include/hw/pci/pci_device.h
+++ b/include/hw/pci/pci_device.h
@@ -160,6 +160,9 @@ struct PCIDevice {
 /* ID of standby device in net_failover pair */
 char *failover_pair_id;
 uint32_t acpi_index;
+
+/* Maximum DMA bounce buffer size used for indirect memory map requests */
+uint64_t max_bounce_buffer_size;
 };
 
 static inline int pci_intx(PCIDevice *pci_dev)
diff --git a/system/memory.c b/system/memory.c
index ad0caef1b8..1cf89654a1 100644
--- a/system/memory.c
+++ b/system/memory.c
@@ -3133,7 +3133,8 @@ void address_space_init(AddressSpace *as, MemoryRegion

[PATCH v8 4/5] vfio-user: Message-based DMA support

Wire up support for DMA for the case where the vfio-user client does not
provide mmap()-able file descriptors, but DMA requests must be performed
via the VFIO-user protocol. This installs an indirect memory region,
which already works for pci_dma_{read,write}, and pci_dma_map works
thanks to the existing DMA bounce buffering support.

Note that while simple scenarios work with this patch, there's a known
race condition in libvfio-user that will mess up the communication
channel. See https://github.com/nutanix/libvfio-user/issues/279 for
details as well as a proposed fix.

Reviewed-by: Jagannathan Raman 
Signed-off-by: Mattias Nissler 
---
 hw/remote/trace-events|   2 +
 hw/remote/vfio-user-obj.c | 100 --
 2 files changed, 87 insertions(+), 15 deletions(-)

diff --git a/hw/remote/trace-events b/hw/remote/trace-events
index 0d1b7d56a5..358a68fb34 100644
--- a/hw/remote/trace-events
+++ b/hw/remote/trace-events
@@ -9,6 +9,8 @@ vfu_cfg_read(uint32_t offset, uint32_t val) "vfu: cfg: 0x%x -> 
0x%x"
 vfu_cfg_write(uint32_t offset, uint32_t val) "vfu: cfg: 0x%x <- 0x%x"
 vfu_dma_register(uint64_t gpa, size_t len) "vfu: registering GPA 0x%"PRIx64", 
%zu bytes"
 vfu_dma_unregister(uint64_t gpa) "vfu: unregistering GPA 0x%"PRIx64""
+vfu_dma_read(uint64_t gpa, size_t len) "vfu: DMA read 0x%"PRIx64", %zu bytes"
+vfu_dma_write(uint64_t gpa, size_t len) "vfu: DMA write 0x%"PRIx64", %zu bytes"
 vfu_bar_register(int i, uint64_t addr, uint64_t size) "vfu: BAR %d: addr 
0x%"PRIx64" size 0x%"PRIx64""
 vfu_bar_rw_enter(const char *op, uint64_t addr) "vfu: %s request for BAR 
address 0x%"PRIx64""
 vfu_bar_rw_exit(const char *op, uint64_t addr) "vfu: Finished %s of BAR 
address 0x%"PRIx64""
diff --git a/hw/remote/vfio-user-obj.c b/hw/remote/vfio-user-obj.c
index d9b879e056..a15e291c9a 100644
--- a/hw/remote/vfio-user-obj.c
+++ b/hw/remote/vfio-user-obj.c
@@ -300,6 +300,63 @@ static ssize_t vfu_object_cfg_access(vfu_ctx_t *vfu_ctx, 
char * const buf,
 return count;
 }
 
+static MemTxResult vfu_dma_read(void *opaque, hwaddr addr, uint64_t *val,
+unsigned size, MemTxAttrs attrs)
+{
+MemoryRegion *region = opaque;
+vfu_ctx_t *vfu_ctx = VFU_OBJECT(region->owner)->vfu_ctx;
+uint8_t buf[sizeof(uint64_t)];
+
+trace_vfu_dma_read(region->addr + addr, size);
+
+g_autofree dma_sg_t *sg = g_malloc0(dma_sg_size());
+vfu_dma_addr_t vfu_addr = (vfu_dma_addr_t)(region->addr + addr);
+if (vfu_addr_to_sgl(vfu_ctx, vfu_addr, size, sg, 1, PROT_READ) < 0 ||
+vfu_sgl_read(vfu_ctx, sg, 1, buf) != 0) {
+return MEMTX_ERROR;
+}
+
+*val = ldn_he_p(buf, size);
+
+return MEMTX_OK;
+}
+
+static MemTxResult vfu_dma_write(void *opaque, hwaddr addr, uint64_t val,
+ unsigned size, MemTxAttrs attrs)
+{
+MemoryRegion *region = opaque;
+vfu_ctx_t *vfu_ctx = VFU_OBJECT(region->owner)->vfu_ctx;
+uint8_t buf[sizeof(uint64_t)];
+
+trace_vfu_dma_write(region->addr + addr, size);
+
+stn_he_p(buf, size, val);
+
+g_autofree dma_sg_t *sg = g_malloc0(dma_sg_size());
+vfu_dma_addr_t vfu_addr = (vfu_dma_addr_t)(region->addr + addr);
+if (vfu_addr_to_sgl(vfu_ctx, vfu_addr, size, sg, 1, PROT_WRITE) < 0 ||
+vfu_sgl_write(vfu_ctx, sg, 1, buf) != 0) {
+return MEMTX_ERROR;
+}
+
+return MEMTX_OK;
+}
+
+static const MemoryRegionOps vfu_dma_ops = {
+.read_with_attrs = vfu_dma_read,
+.write_with_attrs = vfu_dma_write,
+.endianness = DEVICE_HOST_ENDIAN,
+.valid = {
+.min_access_size = 1,
+.max_access_size = 8,
+.unaligned = true,
+},
+.impl = {
+.min_access_size = 1,
+.max_access_size = 8,
+},
+};
+
 static void dma_register(vfu_ctx_t *vfu_ctx, vfu_dma_info_t *info)
 {
 VfuObject *o = vfu_get_private(vfu_ctx);
@@ -308,17 +365,30 @@ static void dma_register(vfu_ctx_t *vfu_ctx, 
vfu_dma_info_t *info)
 g_autofree char *name = NULL;
 struct iovec *iov = >iova;
 
-if (!info->vaddr) {
-return;
-}
-
 name = g_strdup_printf("mem-%s-%"PRIx64"", o->device,
-   (uint64_t)info->vaddr);
+   (uint64_t)iov->iov_base);
 
 subregion = g_new0(MemoryRegion, 1);
 
-memory_region_init_ram_ptr(subregion, NULL, name,
-   iov->iov_len, info->vaddr);
+if (info->vaddr) {
+memory_region_init_ram_ptr(subregion, OBJECT(o), name,
+   iov->iov_len, info->vaddr);
+} else {
+/*
+ * Note that I/O regions' MemoryRegionOps handle accesses of at most 8
+ * bytes at a time, and larger access

[PATCH v8 3/5] Update subprojects/libvfio-user

Brings in assorted bug fixes. The following are of particular interest
with respect to message-based DMA support:

* bb308a2 "Fix address calculation for message-based DMA"
  Corrects a bug in DMA address calculation.

* 1569a37 "Pass server->client command over a separate socket pair"
  Adds support for separate sockets for either command direction,
  addressing a bug where libvfio-user gets confused if both client and
  server send commands concurrently.

Reviewed-by: Jagannathan Raman 
Signed-off-by: Mattias Nissler 
---
 subprojects/libvfio-user.wrap | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/subprojects/libvfio-user.wrap b/subprojects/libvfio-user.wrap
index 416955ca45..cdf0a7a375 100644
--- a/subprojects/libvfio-user.wrap
+++ b/subprojects/libvfio-user.wrap
@@ -1,4 +1,4 @@
 [wrap-git]
 url = https://gitlab.com/qemu-project/libvfio-user.git
-revision = 0b28d205572c80b568a1003db2c8f37ca333e4d7
+revision = 1569a37a54ecb63bd4008708c76339ccf7d06115
 depth = 1
-- 
2.34.1

[PATCH v8 5/5] vfio-user: Fix config space access byte order

PCI config space is little-endian, so on a big-endian host we need to
perform byte swaps for values as they are passed to and received from
the generic PCI config space access machinery.

Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Stefan Hajnoczi 
Reviewed-by: Jagannathan Raman 
Signed-off-by: Mattias Nissler 
---
 hw/remote/vfio-user-obj.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/remote/vfio-user-obj.c b/hw/remote/vfio-user-obj.c
index a15e291c9a..0e93d7a7b4 100644
--- a/hw/remote/vfio-user-obj.c
+++ b/hw/remote/vfio-user-obj.c
@@ -281,7 +281,7 @@ static ssize_t vfu_object_cfg_access(vfu_ctx_t *vfu_ctx, 
char * const buf,
 while (bytes > 0) {
 len = (bytes > pci_access_width) ? pci_access_width : bytes;
 if (is_write) {
-memcpy(, ptr, len);
+val = ldn_le_p(ptr, len);
 pci_host_config_write_common(o->pci_dev, offset,
  pci_config_size(o->pci_dev),
  val, len);
@@ -289,7 +289,7 @@ static ssize_t vfu_object_cfg_access(vfu_ctx_t *vfu_ctx, 
char * const buf,
 } else {
 val = pci_host_config_read_common(o->pci_dev, offset,
   pci_config_size(o->pci_dev), 
len);
-memcpy(ptr, , len);
+stn_le_p(ptr, len, val);
 trace_vfu_cfg_read(offset, val);
 }
 offset += len;
-- 
2.34.1

[PATCH v8 0/5] Support message-based DMA in vfio-user server

This series adds basic support for message-based DMA in qemu's vfio-user
server. This is useful for cases where the client does not provide file
descriptors for accessing system memory via memory mappings. My motivating use
case is to hook up device models as PCIe endpoints to a hardware design. This
works by bridging the PCIe transaction layer to vfio-user, and the endpoint
does not access memory directly, but sends memory requests TLPs to the hardware
design in order to perform DMA.

Note that more work is needed to make message-based DMA work well: qemu
currently breaks down DMA accesses into chunks of size 8 bytes at maximum, each
of which will be handled in a separate vfio-user DMA request message. This is
quite terrible for large DMA accesses, such as when nvme reads and writes
page-sized blocks for example. Thus, I would like to improve qemu to be able to
perform larger accesses, at least for indirect memory regions. I have something
working locally, but since this will likely result in more involved surgery and
discussion, I am leaving this to be addressed in a separate patch.

Changes from v1:

* Address Stefan's review comments. In particular, enforce an allocation limit
  and don't drop the map client callbacks given that map requests can fail when
  hitting size limits.

* libvfio-user version bump now included in the series.

* Tested as well on big-endian s390x. This uncovered another byte order issue
  in vfio-user server code that I've included a fix for.

Changes from v2:

* Add a preparatory patch to make bounce buffering an AddressSpace-specific
  concept.

* The total buffer size limit parameter is now per AdressSpace and can be
  configured for PCIDevice via a property.

* Store a magic value in first bytes of bounce buffer struct as a best effort
  measure to detect invalid pointers in address_space_unmap.

Changes from v3:

* libvfio-user now supports twin-socket mode which uses separate sockets for
  client->server and server->client commands, respectively. This addresses the
  concurrent command bug triggered by server->client DMA access commands. See
  https://github.com/nutanix/libvfio-user/issues/279 for details.

* Add missing teardown code in do_address_space_destroy.

* Fix bounce buffer size bookkeeping race condition.

* Generate unmap notification callbacks unconditionally.

* Some cosmetic fixes.

Changes from v4:

* Fix accidentally dropped memory_region_unref, control flow restored to match
  previous code to simplify review.

* Some cosmetic fixes.

Changes from v5:

* Unregister indirect memory region in libvfio-user dma_unregister callback.

Changes from v6:

* Rebase, resolve straightforward merge conflict in system/dma-helpers.c

Changes from v7:

* Rebase (applied cleanly)

* Restore various Reviewed-by and Tested-by tags that I failed to carry
  forward (I double-checked that the patches haven't changed since the reviewed
  version)

Mattias Nissler (5):
  softmmu: Per-AddressSpace bounce buffering
  softmmu: Support concurrent bounce buffers
  Update subprojects/libvfio-user
  vfio-user: Message-based DMA support
  vfio-user: Fix config space access byte order

 hw/pci/pci.c  |   8 ++
 hw/remote/trace-events|   2 +
 hw/remote/vfio-user-obj.c | 104 +
 include/exec/cpu-common.h |   2 -
 include/exec/memory.h |  41 +-
 include/hw/pci/pci_device.h   |   3 +
 subprojects/libvfio-user.wrap |   2 +-
 system/dma-helpers.c  |   4 +-
 system/memory.c   |   8 ++
 system/physmem.c  | 141 ++
 10 files changed, 226 insertions(+), 89 deletions(-)

-- 
2.34.1

Re: tdsr

2024-03-03 Thread mattias jonsson

yes i run a m1 macbook with mac os sonoma

> 3 mars 2024 kl. 11:30 skrev mattias jonsson :
> 
> have anyone get tdsr working this days?
> i follow all instructions but allways fail with the python module foundation

-- 
The following information is important for all members of the Mac Visionaries 
list.

If you have any questions or concerns about the running of this list, or if you 
feel that a member's post is inappropriate, please contact the owners or 
moderators directly rather than posting on the list itself.

Your Mac Visionaries list moderator is Mark Taylor.  You can reach mark at:  
mk...@ucla.edu and your owner is Cara Quinn - you can reach Cara at 
caraqu...@caraquinn.com

The archives for this list can be searched at:
http://www.mail-archive.com/macvisionaries@googlegroups.com/
--- 
You received this message because you are subscribed to the Google Groups 
"MacVisionaries" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to macvisionaries+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/macvisionaries/4FAD8D37-A1B2-461D-A84B-EC172EEA2E80%40gmail.com.

tdsr

2024-03-03 Thread mattias jonsson

have anyone get tdsr working this days?
i follow all instructions but allways fail with the python module foundation

-- 
The following information is important for all members of the Mac Visionaries 
list.

If you have any questions or concerns about the running of this list, or if you 
feel that a member's post is inappropriate, please contact the owners or 
moderators directly rather than posting on the list itself.

Your Mac Visionaries list moderator is Mark Taylor.  You can reach mark at:  
mk...@ucla.edu and your owner is Cara Quinn - you can reach Cara at 
caraqu...@caraquinn.com

The archives for this list can be searched at:
http://www.mail-archive.com/macvisionaries@googlegroups.com/
--- 
You received this message because you are subscribed to the Google Groups 
"MacVisionaries" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to macvisionaries+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/macvisionaries/8980EC6F-1DBB-48B6-A972-991D855D43FB%40gmail.com.

Re: [fpc-pascal] fpc-pascal Digest, Vol 236, Issue 35

2024-03-01 Thread Mattias Gaertner via fpc-pascal





On 29.02.24 19:21, Jos Wegman via fpc-pascal wrote:

The packages for the Lazarus mac OS x86-64  Lazarus 3.2 on sourceforge are
not correct. There is no compiler package. Instead there are two fpc src
packages. Just a heads-up.


Thanks for the hint. I uploaded the package.

Mattias





Op do 29 feb 2024 12:00 schreef :


Send fpc-pascal mailing list submissions to
 fpc-pascal@lists.freepascal.org

To subscribe or unsubscribe via the World Wide Web, visit
 https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
or, via email, send a message with subject or body 'help' to
 fpc-pascal-requ...@lists.freepascal.org

You can reach the person managing the list at
 fpc-pascal-ow...@lists.freepascal.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of fpc-pascal digest..."


Today's Topics:

1.  Lazarus Bugfix Release 3.2 (Mattias Gaertner)


--

Message: 1
Date: Wed, 28 Feb 2024 16:33:11 +0100
From: Mattias Gaertner 
To: fpc-pascal@lists.freepascal.org
Subject: [fpc-pascal] Lazarus Bugfix Release 3.2
Message-ID: 
Content-Type: text/plain; charset=UTF-8; format=flowed

The Lazarus team is glad to announce the release of Lazarus 3.2.

This is a bugfix release and was built with FPC 3.2.2.

Here is the list of changes for Lazarus and Free Pascal:
http://wiki.lazarus.freepascal.org/Lazarus_3.0_release_notes
http://wiki.lazarus.freepascal.org/User_Changes_3.2.2

Here is the list of fixes for Lazarus 3.x:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/commits/fixes_3_0/

The release is available for download on SourceForge:
http://sourceforge.net/projects/lazarus/files/

Choose your CPU, OS, distro and then the "Lazarus 3.2" directory.

Checksums for the SourceForge files:
https://www.lazarus-ide.org/index.php?page=checksums#3_2

Minimum requirements:

Windows:
2k, 32 or 64bit, Qt, Qt5, Qt6 (64bit only)

FreeBSD/Linux:
gtk 2.24 for gtk2, qt4.5 for qt, qt5.6 for qt5, Qt6.2 for qt6, 32 or
64bit.

Mac OS X:
Cocoa (64bit) 10.12, Carbon (32bit) 10.5 to 10.14, Qt and Qt5 (32 or
64bit), Qt6 (64bit only).

Note: Since Macos Sonoma 14 debugging takes some time to start the
application, especially on first start.


Mattias


--

Subject: Digest Footer

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


--

End of fpc-pascal Digest, Vol 236, Issue 35
***




___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [PATCH, v2] physmem: avoid bounce buffer too small

On Thu, Feb 29, 2024 at 1:35 PM Peter Maydell  wrote:
>
> On Thu, 29 Feb 2024 at 11:17, Heinrich Schuchardt
>  wrote:
> > > But yes, I'm not surprised that CXL runs into this. Heinrich,
> > > are you doing CXL testing, or is this some other workload?
> >
> > I am running the UEFI Self-Certification Tests (SCT) on EDK 2 using:
> >
> > qemu-system-riscv64 \
> >-M virt,acpi=off -accel tcg -m 4096 \
> >-serial mon:stdio \
> >-device virtio-gpu-pci \
> >-device qemu-xhci \
> >-device usb-kbd \
> >-drive
> > if=pflash,format=raw,unit=0,file=RISCV_VIRT_CODE.fd,readonly=on \
> >-drive if=pflash,format=raw,unit=1,file=RISCV_VIRT_VARS.fd \
> >-drive file=sct.img,format=raw,if=virtio \
> >-device virtio-net-device,netdev=net0 \
> >-netdev user,id=net0
> >
> > This does not invoke any CXL related stuff.
>
> Hmm, that doesn't seem like it ought to be running into this.
> What underlying memory region is the guest trying to do
> the virtio queue access to?

FWIW, I have seen multiple bounce buffer usage with the generic net TX
path as well as the XHCI controller, so it might be either of these.
Bounce buffering should only take place when the memory region can't
be accessed directly though - I don't see why that's the case for the
given command line.

Re: [PATCH, v2] physmem: avoid bounce buffer too small

On Thu, Feb 29, 2024 at 12:12 PM Peter Maydell  wrote:
>
> On Thu, 29 Feb 2024 at 10:59, Jonathan Cameron
>  wrote:
> >
> > On Thu, 29 Feb 2024 09:38:29 +
> > Peter Maydell  wrote:
> >
> > > On Wed, 28 Feb 2024 at 19:07, Heinrich Schuchardt
> > >  wrote:
> > > >
> > > > On 28.02.24 19:39, Peter Maydell wrote:
> > > > > The limitation to a page dates back to commit 6d16c2f88f2a in 2009,
> > > > > which was the first implementation of this function. I don't think
> > > > > there's a particular reason for that value beyond that it was
> > > > > probably a convenient value that was assumed to be likely "big 
> > > > > enough".
> > > > >
> > > > > I think the idea with this bounce-buffer has always been that this
> > > > > isn't really a code path we expected to end up in very often --
> > > > > it's supposed to be for when devices are doing DMA, which they
> > > > > will typically be doing to memory (backed by host RAM), not
> > > > > devices (backed by MMIO and needing a bounce buffer). So the
> > > > > whole mechanism is a bit "last fallback to stop things breaking
> > > > > entirely".
> > > > >
> > > > > The address_space_map() API says that it's allowed to return
> > > > > a subset of the range you ask for, so if the virtio code doesn't
> > > > > cope with the minimum being set to TARGET_PAGE_SIZE then either
> > > > > we need to fix that virtio code or we need to change the API
> > > > > of this function. (But I think you will also get a reduced
> > > > > range if you try to use it across a boundary between normal
> > > > > host-memory-backed RAM and a device MemoryRegion.)
> > > >
> > > > If we allow a bounce buffer only to be used once (via the in_use flag),
> > > > why do we allow only a single bounce buffer?
> > > >
> > > > Could address_space_map() allocate a new bounce buffer on every call and
> > > > address_space_unmap() deallocate it?
> > > >
> > > > Isn't the design with a single bounce buffer bound to fail with a
> > > > multi-threaded client as collision can be expected?
> > >
> > > Yeah, I don't suppose multi-threaded was particularly expected.
> > > Again, this is really a "handle the case where the guest does
> > > something silly" setup, which is why only one bounce buffer.
> > >
> > > Why is your guest ending up in the bounce-buffer path?
> >
> > Happens for me with emulated CXL memory.
>
> Can we put that in the "something silly" bucket? :-)
> But yes, I'm not surprised that CXL runs into this. Heinrich,
> are you doing CXL testing, or is this some other workload?
>
> > I think the case I saw
> > was split descriptors in virtio via address space caches
> > https://elixir.bootlin.com/qemu/latest/source/hw/virtio/virtio.c#L4043
> >
> > One bounce buffer is in use for the outer loop and another for the 
> > descriptors
> > it is pointing to.
>
> Mmm. The other assumption made in the design of the address_space_map()
> API I think was that it was unlikely that a device would be trying
> to do two DMA operations simultaneously. This is clearly not
> true in practice. We definitely need to fix one end or other of
> this API.
>
> (I'm not sure why the bounce-buffer limit ought to be per-AddressSpace:
> is that just done in Matthias' series so that we can attach an
> x-thingy property to the individual PCI device?)

Yes, that's the result of review feedback to the early iterations of
my series. Specifically, (1) a limit is needed to prevent rogue guests
from hogging unlimited amounts of memory and (2) global parameters are
frowned upon. Setting a suitable limit is much more practical when
targeted at a given device/driver combination.

Re: [PATCH v7 0/5] Support message-based DMA in vfio-user server

Hi,

I actually failed to carry forward the Reviewed-by tags from Jag,
Phillipe and Stefan as well when reposting even though I didn't make
any non-trivial changes to the respective patches. I intend to post
another version with the respective tags restored, but I'll give you a
day or two to speak up if you disagree.

Thanks,
Mattias

On Tue, Feb 20, 2024 at 6:06 AM Peter Xu  wrote:
>
> On Mon, Feb 12, 2024 at 12:06:12AM -0800, Mattias Nissler wrote:
> > Changes from v6:
> >
> > * Rebase, resolve straightforward merge conflict in system/dma-helpers.c
>
> Hi, Mattias,
>
> If the change is trivial, feel free to carry over my R-bs in the first two
> patches in the commit message.
>
> Thanks,
>
> --
> Peter Xu
>

Re: [PATCH, v2] physmem: avoid bounce buffer too small

On Thu, Feb 29, 2024 at 11:22 AM Heinrich Schuchardt
 wrote:
>
> On 29.02.24 02:11, Peter Xu wrote:
> > On Wed, Feb 28, 2024 at 08:07:47PM +0100, Heinrich Schuchardt wrote:
> >> On 28.02.24 19:39, Peter Maydell wrote:
> >>> On Wed, 28 Feb 2024 at 18:28, Heinrich Schuchardt
> >>>  wrote:
> 
>  On 28.02.24 16:06, Philippe Mathieu-Daudé wrote:
> > Hi Heinrich,
> >
> > On 28/2/24 13:59, Heinrich Schuchardt wrote:
> >> virtqueue_map_desc() is called with values of sz exceeding that may
> >> exceed
> >> TARGET_PAGE_SIZE. sz = 0x2800 has been observed.
> >
> > Pure (and can also be stupid) question: why virtqueue_map_desc() would map
> > to !direct mem?  Shouldn't those buffers normally allocated from guest RAM?
> >
> >>
> >> We only support a single bounce buffer. We have to avoid
> >> virtqueue_map_desc() calling address_space_map() multiple times.
> >> Otherwise
> >> we see an error
> >>
> >>qemu: virtio: bogus descriptor or out of resources
> >>
> >> Increase the minimum size of the bounce buffer to 0x1 which matches
> >> the largest value of TARGET_PAGE_SIZE for all architectures.
> >>
> >> Signed-off-by: Heinrich Schuchardt 
> >> ---
> >> v2:
> >>   remove unrelated change
> >> ---
> >> system/physmem.c | 8 ++--
> >> 1 file changed, 6 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/system/physmem.c b/system/physmem.c
> >> index e3ebc19eef..3c82da1c86 100644
> >> --- a/system/physmem.c
> >> +++ b/system/physmem.c
> >> @@ -3151,8 +3151,12 @@ void *address_space_map(AddressSpace *as,
> >> *plen = 0;
> >> return NULL;
> >> }
> >> -/* Avoid unbounded allocations */
> >> -l = MIN(l, TARGET_PAGE_SIZE);
> >> +/*
> >> + * There is only one bounce buffer. The largest occuring
> >> value of
> >> + * parameter sz of virtqueue_map_desc() must fit into the 
> >> bounce
> >> + * buffer.
> >> + */
> >> +l = MIN(l, 0x1);
> >
> > Please define this magic value. Maybe ANY_TARGET_PAGE_SIZE or
> > TARGETS_BIGGEST_PAGE_SIZE?
> >
> > Then along:
> >  QEMU_BUILD_BUG_ON(TARGET_PAGE_SIZE <= TARGETS_BIGGEST_PAGE_SIZE);
> 
>  Thank you Philippe for reviewing.
> 
>  TARGETS_BIGGEST_PAGE_SIZE does not fit as the value is not driven by the
>  page size.
>  How about MIN_BOUNCE_BUFFER_SIZE?
>  Is include/exec/memory.h the right include for the constant?
> 
>  I don't think that TARGET_PAGE_SIZE has any relevance for setting the
>  bounce buffer size. I only mentioned it to say that we are not
>  decreasing the value on any existing architecture.
> 
>  I don't know why TARGET_PAGE_SIZE ever got into this piece of code.
>  e3127ae0cdcd ("exec: reorganize address_space_map") does not provide a
>  reason for this choice. Maybe Paolo remembers.
> >>>
> >>> The limitation to a page dates back to commit 6d16c2f88f2a in 2009,
> >>> which was the first implementation of this function. I don't think
> >>> there's a particular reason for that value beyond that it was
> >>> probably a convenient value that was assumed to be likely "big enough".
> >>>
> >>> I think the idea with this bounce-buffer has always been that this
> >>> isn't really a code path we expected to end up in very often --
> >>> it's supposed to be for when devices are doing DMA, which they
> >>> will typically be doing to memory (backed by host RAM), not
> >>> devices (backed by MMIO and needing a bounce buffer). So the
> >>> whole mechanism is a bit "last fallback to stop things breaking
> >>> entirely".
> >>>
> >>> The address_space_map() API says that it's allowed to return
> >>> a subset of the range you ask for, so if the virtio code doesn't
> >>> cope with the minimum being set to TARGET_PAGE_SIZE then either
> >>> we need to fix that virtio code or we need to change the API
> >>> of this function. (But I think you will also get a reduced
> >>> range if you try to use it across a boundary between normal
> >>> host-memory-backed RAM and a device MemoryRegion.)
> >>
> >> If we allow a bounce buffer only to be used once (via the in_use flag), why
> >> do we allow only a single bounce buffer?
> >>
> >> Could address_space_map() allocate a new bounce buffer on every call and
> >> address_space_unmap() deallocate it?
> >>
> >> Isn't the design with a single bounce buffer bound to fail with a
> >> multi-threaded client as collision can be expected?
> >
> > See:
> >
> > https://lore.kernel.org/r/20240212080617.2559498-1-mniss...@rivosinc.com
> >
> > For some reason that series didn't land, but it seems to be helpful in this
> > case too if e.g. there can be multiple of such devices.
> >
> > Thanks,
> >
>
> Hello Peter Xu,
>
> thanks for pointing to your series. What I like

[fpc-pascal] Lazarus Bugfix Release 3.2

2024-02-28 Thread Mattias Gaertner via fpc-pascal


The Lazarus team is glad to announce the release of Lazarus 3.2.

This is a bugfix release and was built with FPC 3.2.2.

Here is the list of changes for Lazarus and Free Pascal:
http://wiki.lazarus.freepascal.org/Lazarus_3.0_release_notes
http://wiki.lazarus.freepascal.org/User_Changes_3.2.2

Here is the list of fixes for Lazarus 3.x:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/commits/fixes_3_0/

The release is available for download on SourceForge:
http://sourceforge.net/projects/lazarus/files/

Choose your CPU, OS, distro and then the "Lazarus 3.2" directory.

Checksums for the SourceForge files:
https://www.lazarus-ide.org/index.php?page=checksums#3_2

Minimum requirements:

Windows:
  2k, 32 or 64bit, Qt, Qt5, Qt6 (64bit only)

FreeBSD/Linux:
  gtk 2.24 for gtk2, qt4.5 for qt, qt5.6 for qt5, Qt6.2 for qt6, 32 or 
64bit.


Mac OS X:
  Cocoa (64bit) 10.12, Carbon (32bit) 10.5 to 10.14, Qt and Qt5 (32 or 
64bit), Qt6 (64bit only).


Note: Since Macos Sonoma 14 debugging takes some time to start the 
application, especially on first start.



Mattias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-other] Lazarus Bugfix Release 3.2

2024-02-28 Thread Mattias Gaertner via fpc-other


The Lazarus team is glad to announce the release of Lazarus 3.2.

This is a bugfix release and was built with FPC 3.2.2.

Here is the list of changes for Lazarus and Free Pascal:
http://wiki.lazarus.freepascal.org/Lazarus_3.0_release_notes
http://wiki.lazarus.freepascal.org/User_Changes_3.2.2

Here is the list of fixes for Lazarus 3.x:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/commits/fixes_3_0/

The release is available for download on SourceForge:
http://sourceforge.net/projects/lazarus/files/

Choose your CPU, OS, distro and then the "Lazarus 3.2" directory.

Checksums for the SourceForge files:
https://www.lazarus-ide.org/index.php?page=checksums#3_2

Minimum requirements:

Windows:
  2k, 32 or 64bit, Qt, Qt5, Qt6 (64bit only)

FreeBSD/Linux:
  gtk 2.24 for gtk2, qt4.5 for qt, qt5.6 for qt5, Qt6.2 for qt6, 32 or 
64bit.


Mac OS X:
  Cocoa (64bit) 10.12, Carbon (32bit) 10.5 to 10.14, Qt and Qt5 (32 or 
64bit), Qt6 (64bit only).


Note: Since Macos Sonoma 14 debugging takes some time to start the 
application, especially on first start.



Mattias
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

[Lazarus] Lazarus Bugfix Release 3.2

2024-02-28 Thread Mattias Gaertner via lazarus


The Lazarus team is glad to announce the release of Lazarus 3.2.

This is a bugfix release and was built with FPC 3.2.2.

Here is the list of changes for Lazarus and Free Pascal:
http://wiki.lazarus.freepascal.org/Lazarus_3.0_release_notes
http://wiki.lazarus.freepascal.org/User_Changes_3.2.2

Here is the list of fixes for Lazarus 3.x:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/commits/fixes_3_0/

The release is available for download on SourceForge:
http://sourceforge.net/projects/lazarus/files/

Choose your CPU, OS, distro and then the "Lazarus 3.2" directory.

Checksums for the SourceForge files:
https://www.lazarus-ide.org/index.php?page=checksums#3_2

Minimum requirements:

Windows:
  2k, 32 or 64bit, Qt, Qt5, Qt6 (64bit only)

FreeBSD/Linux:
  gtk 2.24 for gtk2, qt4.5 for qt, qt5.6 for qt5, Qt6.2 for qt6, 32 or 
64bit.


Mac OS X:
  Cocoa (64bit) 10.12, Carbon (32bit) 10.5 to 10.14, Qt and Qt5 (32 or 
64bit), Qt6 (64bit only).


Note: Since Macos Sonoma 14 debugging takes some time to start the 
application, especially on first start.



Mattias
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[blind-gamers] manamon 2

2024-02-28 Thread mattias

Near the modernt iland (Spelling)You can dive down if you have a lucishWhats the Point there?Or are it a postgame  Skickades från E-post för Windows 


_._,_._,_



Groups.io Links:


  
You receive all messages sent to this group.
  
  



View/Reply Online (#127213) |


  Reply To Group
  

|

  Mute This Topic


| New Topic






Your Subscription |
Contact Group Owner |

Unsubscribe

 [arch...@mail-archive.com]
_._,_._,_

[Kernel-packages] [Bug 2044657] Re: Multiple data corruption issues in zfs

2024-02-22 Thread Mattias Heimlich

I don't get it. The latest ZFS version in Jammy seem to be 2.1.5 and not
2.1.14 nor 2.2.2. When will the committed version with the fix be
available to the general public?

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
https://bugs.launchpad.net/bugs/2044657

Title:
  Multiple data corruption issues in zfs

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Xenial:
  Confirmed
Status in zfs-linux source package in Bionic:
  Confirmed
Status in zfs-linux source package in Focal:
  Fix Committed
Status in zfs-linux source package in Jammy:
  Fix Committed
Status in zfs-linux source package in Lunar:
  Won't Fix
Status in zfs-linux source package in Mantic:
  Fix Released
Status in zfs-linux source package in Noble:
  Fix Released

Bug description:
  [ Impact ]

   * Multiple data corruption issues have been identified and fixed in
  ZFS. Some of them, at varying real-life reproducibility frequency have
  been deterimed to affect very old zfs releases. Recommendation is to
  upgrade to 2.2.2 or 2.1.14 or backport dnat patch alone. This is to
  ensure users get other potentially related fixes and runtime tunables
  to possibly mitigate other bugs that are related and are being fixed
  upstream for future releases.

   * For jammy the 2.1.14 upgrade will bring HWE kernel support and also
  compatiblity/support for hardened kernel builds that mitigate SLS
  (straight-line-speculation).

   * In the absence of the upgrade a cherry-pick will address this
  particular popular issue alone - without addressing other issues
  w.r.t. Redbleed / SLS, bugfixes around trim support, and other related
  improvements that were discovered and fixed around the same time as
  this popular issue.

  [ Test Plan ]

   * !!! Danger !!! use reproducer from
  https://zfsonlinux.topicbox.com/groups/zfs-discuss/T12876116b8607cdb
  and confirm if that issue is resolved or not. Do not run on production
  ZFS pools / systems.

   * autopkgtest pass (from https://ubuntu-archive-
  team.ubuntu.com/proposed-migration/ )

   * adt-matrix pass (from https://kernel.ubuntu.com/adt-matrix/ )

   * kernel regression zfs testsuite pass (from Kernel team RT test
  results summary, private)

   * zsys integration test pass (upgrade of zsys installed systems for
  all releases)

   * zsys install test pass (for daily images of LTS releases only that
  have such installer support, as per iso tracker test case)

   * LXD (ping LXD team to upgrade vendored in tooling to 2.2.2 and
  2.1.14, and test LXD on these updated kernels)

  [ Where problems could occur ]

   * Upgrade to 2.1.14 on jammy with SLS mitigations compatiblity will
  introduce slight slow down on amd64 (for hw accelerated assembly code-
  paths only in the encryption primitives)

   * Uncertain of the perfomance impact of the extra checks in dnat
  patch fix itself. Possibly affecting speed of operation, at the
  benefit of correctness.

   * The cherry-picked patch ("dnat"? dnode) changes the dirty data check, but
 only makes it stronger and not weaker, thus if it were incorrect, likely
 only performance would be impacted (and it is unlikely to be incorrect
 given upstream reviews and attention to data corruption issues; also,
 there are no additional changes to that function upstream)

  [ Other Info ]

   * https://github.com/openzfs/zfs/pull/15571 is most current
  consideration of affairs

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2044657/+subscriptions


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Re: [blink-dev] Intent to Prototype and Ship: Streams API: ReadableStream async iteration

2024-02-21 Thread Mattias Buelens

Thanks Chris, they're all blue now.

Op woensdag 21 februari 2024 om 18:09:55 UTC+1 schreef chri...@google.com:

> Hi,
>
> Please start the reviews for the 5 other areas shown below in your 
> chromestatus entry (once you've done show they should turn blue, not gray):
>
> [image: Screenshot 2024-02-21 9.08.57 AM.png]
>
>
> On Wed, Feb 21, 2024 at 8:03 AM Yoav Weiss (@Shopify) <
> yoav...@chromium.org> wrote:
>
>> LGTM1
>>
>> Thanks for catching us up here!!
>>
>> On Wed, Feb 21, 2024 at 4:57 PM Mattias Buelens  
>> wrote:
>>
>>> Contact emails
>>>
>>> mattias...@gmail.com
>>>
>>> Explainer
>>>
>>>
>>> https://github.com/whatwg/streams/blob/main/readable-stream-async-iteration-explainer.md
>>>
>>> Specification
>>>
>>> https://streams.spec.whatwg.org/#rs-asynciterator
>>>
>>> Summary
>>>
>>> The streams APIs provide ubiquitous, interoperable primitives for 
>>> creating, composing, and consuming streams of data. This change adds 
>>> support for the async iterable protocol to the ReadableStream API, enabling 
>>> readable streams to be used as the source of for await...of loops.
>>>
>>>
>>> Blink component
>>>
>>> Blink>Network>StreamsAPI 
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork%3EStreamsAPI>
>>>
>>> Motivation
>>>
>>> To consume a ReadableStream, developers currently acquire a reader and 
>>> repeatedly call read(). By adding support for the async iterable protocol, 
>>> web developers will be able to use the much simpler for await...of syntax 
>>> to loop over all chunks of a ReadableStream.
>>>
>>> Web developers are already using polyfills to async-iterate over a 
>>> ReadableStream. These polyfills usually work fine, but might not handle all 
>>> edge cases correctly (such as when the stream errors during a read, or 
>>> releasing the reader's lock when breaking out of a for await...of loop).
>>>
>>>
>>> Initial public proposal
>>>
>>> None
>>>
>>> Search tags
>>>
>>> streams <https://chromestatus.com/features#tags:streams>
>>>
>>> TAG review
>>>
>>> None
>>>
>>> TAG review status
>>>
>>> Not applicable. (This is a small feature with a mature specification 
>>> that's already shipping in Firefox.)
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> Low risk. The Streams API has already been standardised for a long time. 
>>> Async iteration is already supported in one other browser (Firefox) and 
>>> several JavaScript runtimes (Node.js, Deno, bun).
>>>
>>>
>>> Gecko: Shipped/Shipping (
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1525852) Shipped in 
>>> Firefox 110
>>>
>>> WebKit: No signal (
>>> https://github.com/WebKit/standards-positions/issues/319)
>>>
>>> Web developers: Positive (https://github.com/whatwg/streams/issues/778) 
>>> Developers already expect this to work, and often use a polyfill.
>>>
>>> Other signals:
>>>
>>> Activation
>>>
>>> Async iteration can be feature detected by checking the existence of 
>>> `ReadableStream.prototype.values`. Various polyfills already exist in the 
>>> wild. (e.g. 
>>> https://jakearchibald.com/2017/async-iterators-and-generators/)
>>>
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such 
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> None
>>>
>>>
>>> Debuggability
>>>
>>> No special support needed. The JavaScript debugger is already 
>>> sufficiently capable of handling for await...of loops.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests 
>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>> ?
>>>
>>> Yes
>>>
>>> https://wpt.fyi/results/streams/readable-streams/async-iterator.any.html
>>>
>>>
>>> Flag name on chrome://flags
>>>
>>> None
>>>
>>> Finch feature name
>>>
>>> ReadableStreamAsyncIterable
>>>

[blink-dev] Intent to Prototype and Ship: Streams API: ReadableStream async iteration

2024-02-21 Thread Mattias Buelens

Contact emails

mattias.buel...@gmail.com

Explainer

https://github.com/whatwg/streams/blob/main/readable-stream-async-iteration-explainer.md

Specification

https://streams.spec.whatwg.org/#rs-asynciterator

Summary

The streams APIs provide ubiquitous, interoperable primitives for creating,
composing, and consuming streams of data. This change adds support for the
async iterable protocol to the ReadableStream API, enabling readable
streams to be used as the source of for await...of loops.

Blink component

Blink>Network>StreamsAPI

Motivation

To consume a ReadableStream, developers currently acquire a reader and
repeatedly call read(). By adding support for the async iterable protocol,
web developers will be able to use the much simpler for await...of syntax
to loop over all chunks of a ReadableStream.

Web developers are already using polyfills to async-iterate over a
ReadableStream. These polyfills usually work fine, but might not handle all
edge cases correctly (such as when the stream errors during a read, or
releasing the reader's lock when breaking out of a for await...of loop).

Initial public proposal

None

Search tags

streams

TAG review

None

TAG review status

Not applicable. (This is a small feature with a mature specification that's
already shipping in Firefox.)

Risks

Interoperability and Compatibility

Low risk. The Streams API has already been standardised for a long time.
Async iteration is already supported in one other browser (Firefox) and
several JavaScript runtimes (Node.js, Deno, bun).

Gecko: Shipped/Shipping (
https://bugzilla.mozilla.org/show_bug.cgi?id=1525852) Shipped in Firefox 110

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/319)

Web developers: Positive (https://github.com/whatwg/streams/issues/778)
Developers already expect this to work, and often use a polyfill.

Other signals:

Activation

Async iteration can be feature detected by checking the existence of
`ReadableStream.prototype.values`. Various polyfills already exist in the
wild. (e.g. https://jakearchibald.com/2017/async-iterators-and-generators/)

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

None

Debuggability

No special support needed. The JavaScript debugger is already sufficiently
capable of handling for await...of loops.

Is this feature fully tested by web-platform-tests

Yes

https://wpt.fyi/results/streams/readable-streams/async-iterator.any.html

Flag name on chrome://flags

None

Finch feature name

ReadableStreamAsyncIterable

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/40612900

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5143121161879552

This intent message was generated by Chrome Platform Status
.

--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b1438dfd-ec71-4e18-b34d-0213aff6250cn%40chromium.org.

Re: VMware Fusion/Player

2024-02-20 Thread mattias jonsson

i wonder if narrator are removed from newer windows arm builds setup

> 19 feb. 2024 kl. 21:17 skrev 'Janina Sajka' via MacVisionaries 
> :
> 
> There's an available license that's free of charge. It's available to
> students and to other categories they name. I have had one based on my
> W3C activities for some time.
> 
> However, I've been unable to renew. It's been very frustrating.
> 
> Janina
> 
> Anders Holmberg writes:
>> Hi!
>> Is the fusion free of charge or do I have to pay for it?
>> Bless.
>> /A
>> 
>>> 11 feb. 2024 kl. 15:57 skrev 'Matt Turner' via MacVisionaries 
>>> :
>>> 
>>> I get this when I try to install windows 11.
>>> Check your Startup Disk in the virtual machine settings. If you have not 
>>> installed an operating system yet, you can choose an installation disc or 
>>> disc image in the CD/DVD settings and restart the virtual machine.
>>> I???m on an Intel mac.
>>> On Feb 11, 2024, at 8:37 AM, Anders Holmberg  wrote:
 
 Hi!
 Vocr is so hard to use.
 I have tried that but was wondering should I turn off VoiceOver?
 /A
 
> 11 feb. 2024 kl. 00:57 skrev Kelly Ford :
> 
> Well,
> 
> I am now running a VMWare VM on my M1 Mac. I have to use VOCR to get 
> through setup and then add VMWare tools.  Only then did I get Narrator 
> sound.
> 
> I???m not entirely sure why because I did get the windows startup sound 
> after going through the first steps of OS install where you enter a 
> product key and such. But I didn???t have Narrator speech.
> 
> Kelly
> 
> 
>> On Feb 10, 2024, at 5:28???PM, Kelly Ford  wrote:
>> 
>> Hi,
>> 
>> For what it is worth, my Mac updated to the latest developer beta today. 
>> VMware virtual machines do not shutdown immediately any longer but I???m 
>> not getting any sound from a VM to use Narrator during OS install
>> 
>> I am trying to get through it with VOCR so we will see.
>> 
>> 
>> 
>>> On Feb 9, 2024, at 9:50???AM, Anders Holmberg  
>>> wrote:
>>> 
>>> Hi!
>>> Hi!
>>> Vocr is very very tedious.
>>> So I rather not use any virtual machine.
>>> I will try to find a refurbished laptop that I can install linux onto 
>>> or windows.
>>> Bless.
>>> /A
 8 feb. 2024 kl. 03:02 skrev 'Sabahattin Gucukoglu' via MacVisionaries 
 :
 
 How do you find Parallels? Are you all right using VOCR? I find it 
 very tedious and definitely would prefer to avoid that.
 
 -- 
 The following information is important for all members of the Mac 
 Visionaries list.
 
 If you have any questions or concerns about the running of this list, 
 or if you feel that a member's post is inappropriate, please contact 
 the owners or moderators directly rather than posting on the list 
 itself.
 
 Your Mac Visionaries list moderator is Mark Taylor.  You can reach 
 mark at:  mk...@ucla.edu and your owner is Cara Quinn - you can reach 
 Cara at caraqu...@caraquinn.com
 
 The archives for this list can be searched at:
 http://www.mail-archive.com/macvisionaries@googlegroups.com/
 --- 
 You received this message because you are subscribed to the Google 
 Groups "MacVisionaries" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to macvisionaries+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/macvisionaries/53ECE646-4CE0-404E-869C-70CF382200A7%40me.com.
>>> 
>>> -- 
>>> The following information is important for all members of the Mac 
>>> Visionaries list.
>>> 
>>> If you have any questions or concerns about the running of this list, 
>>> or if you feel that a member's post is inappropriate, please contact 
>>> the owners or moderators directly rather than posting on the list 
>>> itself.
>>> 
>>> Your Mac Visionaries list moderator is Mark Taylor.  You can reach mark 
>>> at:  mk...@ucla.edu and your owner is Cara Quinn - you can reach Cara 
>>> at caraqu...@caraquinn.com
>>> 
>>> The archives for this list can be searched at:
>>> http://www.mail-archive.com/macvisionaries@googlegroups.com/
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "MacVisionaries" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to macvisionaries+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/macvisionaries/3E421955-BC0E-4561-BBC7-6BCDAF63F0A9%40pipkrokodil.se.
>> 
> 
> -- 
> The following information is important for all members of the Mac 
> Visionaries list.
>

Re: Crash with CXL + TCG on 8.2: Was Re: qemu cxl memory expander shows numa_node -1

2024-02-18 Thread Mattias Nissler

On Thu, Feb 15, 2024 at 4:29 PM Jonathan Cameron <
jonathan.came...@huawei.com> wrote:

> On Thu, 8 Feb 2024 14:50:59 +
> Jonathan Cameron  wrote:
>
> > On Wed, 7 Feb 2024 17:34:15 +
> > Jonathan Cameron  wrote:
> >
> > > On Fri, 2 Feb 2024 16:56:18 +
> > > Peter Maydell  wrote:
> > >
> > > > On Fri, 2 Feb 2024 at 16:50, Gregory Price <
> gregory.pr...@memverge.com> wrote:
> > > > >
> > > > > On Fri, Feb 02, 2024 at 04:33:20PM +, Peter Maydell wrote:
>
> > > > > > Here we are trying to take an interrupt. This isn't related to
> the
> > > > > > other can_do_io stuff, it's happening because do_ld_mmio_beN
> assumes
> > > > > > it's called with the BQL not held, but in fact there are some
> > > > > > situations where we call into the memory subsystem and we do
> > > > > > already have the BQL.
> > > >
> > > > > It's bugs all the way down as usual!
> > > > > https://xkcd.com/1416/
> > > > >
> > > > > I'll dig in a little next week to see if there's an easy fix. We
> can see
> > > > > the return address is already 0 going into mmu_translate, so it
> does
> > > > > look unrelated to the patch I threw out - but probably still has
> to do
> > > > > with things being on IO.
> > > >
> > > > Yes, the low level memory accessors only need to take the BQL if the
> thing
> > > > being accessed is an MMIO device. Probably what is wanted is for
> those
> > > > functions to do "take the lock if we don't already have it",
> something
> > > > like hw/core/cpu-common.c:cpu_reset_interrupt() does.
> >
> > Got back to x86 testing and indeed not taking the lock in that one path
> > does get things running (with all Gregory's earlier hacks + DMA limits as
> > described below).  Guess it's time to roll some cleaned up patches and
> > see how much everyone screams :)
> >
>
> 3 series sent out:
> (all also on gitlab.com/jic23/qemu cxl-2024-02-15 though I updated patch
> descriptions
> a little after pushing that out)
>
> Main set of fixes (x86 'works' under my light testing after this one)
>
> https://lore.kernel.org/qemu-devel/20240215150133.2088-1-jonathan.came...@huawei.com/
>
> ARM FEAT_HADFS (access and dirty it updating in PTW) workaround for
> missing atomic CAS
>
> https://lore.kernel.org/qemu-devel/20240215151804.2426-1-jonathan.came...@huawei.com/T/#t
>
> DMA / virtio fix:
>
> https://lore.kernel.org/qemu-devel/20240215142817.1904-1-jonathan.came...@huawei.com/
>
> Last thing I need to do is propose a suitable flag to make
> Mattias' bounce buffering size parameter apply to "memory" address space.


For background, I actually had a global bounce buffer size parameter apply
to all address spaces in an earlier version of my series. After discussion
on the list, we settled on an address-space specific parameter so it can be
configured per device. I haven't looked into where the memory accesses in
your context originate from - can they be attributed to a specific entity
to house the parameter?


> Currently
> I'm carrying this: (I've no idea how much is need but it's somewhere
> between 4k and 1G)
>
> diff --git a/system/physmem.c b/system/physmem.c
> index 43b37942cf..49b961c7a5 100644
> --- a/system/physmem.c
> +++ b/system/physmem.c
> @@ -2557,6 +2557,7 @@ static void memory_map_init(void)
>  memory_region_init(system_memory, NULL, "system", UINT64_MAX);
>  address_space_init(_space_memory, system_memory, "memory");
>
> +address_space_memory.max_bounce_buffer_size = 1024 * 1024 * 1024;
>  system_io = g_malloc(sizeof(*system_io));
>  memory_region_init_io(system_io, NULL, _io_ops, NULL, "io",
>65536);
>
> Please take a look. These are all in areas of QEMU I'm not particularly
> confident
> about so relying on nice people giving feedback even more than normal!
>
> Thanks to all those who helped with debugging and suggestions.
>
> Thanks,
>
> Jonathan
>
> > Jonathan
> >
> >
> > > >
> > > > -- PMM
> > >
> > > Still a work in progress but I thought I'd give an update on some of
> the fun...
> > >
> > > I have a set of somewhat dubious workarounds that sort of do the job
> (where
> > > the aim is to be able to safely run any workload on top of any valid
> > > emulated CXL device setup).
> > >
> > > To recap, the i

attapoll

2024-02-17 Thread mattias jonsson

have anyone tryed attapoll with vo?
the app itself works
but how to accept the agreement?

-- 
The following information is important for all members of the Mac Visionaries 
list.

If you have any questions or concerns about the running of this list, or if you 
feel that a member's post is inappropriate, please contact the owners or 
moderators directly rather than posting on the list itself.

Your Mac Visionaries list moderator is Mark Taylor.  You can reach mark at:  
mk...@ucla.edu and your owner is Cara Quinn - you can reach Cara at 
caraqu...@caraquinn.com

The archives for this list can be searched at:
http://www.mail-archive.com/macvisionaries@googlegroups.com/
--- 
You received this message because you are subscribed to the Google Groups 
"MacVisionaries" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to macvisionaries+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/macvisionaries/C0065148-5075-48B4-BBD5-12A3D75EBF08%40gmail.com.

[FFmpeg-cvslog] avcodec/h2645_parse: Don't treat 0x000002 as a start code and truncate

2024-02-17 Thread Mattias Wadman

ffmpeg | branch: master | Mattias Wadman  | Tue Feb 
13 11:17:46 2024 +0100| [78812cd147fa2ab1f0aa3019886c0abe00b7c63a] | committer: 
Anton Khirnov

avcodec/h2645_parse: Don't treat 0x02 as a start code and truncate

According to ITU-T H.265 7.4.2.1 this byte sequence should not appear in a
NAL unit but in practice in rare cases it seems it does, possibly due to buggy
encoders. Other players like VLC and Quicktime seem to be fine with it.

Currently when this sequence is found it is treated as if the next start code
has been found and the NAL unit gets truncated.

This change limits the code to only look for first start code 0x001 or
first escape 0x03.

Sadly i can't share the original source file with the issue but the first
80 bytes of the NAL unit looks like this:

   │00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f│0123456789abcdef│
0x0│00 00 00 01 02 01 d0 bc 57 a1 b8 44 70 01 00 0b│W..Dp...│
0x00010│80 2e 00 c2 6c ec 3e b9 e3 03 fb 91 2e d2 43 cb│l.>...C.│
0x00020│1d 2c 00 00 02 00 02 00 5c 93 72 6f 31 76 18 00│.,..\.ro1v..│
0x00030│08 38 aa b1 4c 33 3f fd 08 cb 77 9b d4 3c db 02│.8..L3?...w..<..│
0x00040│a2 04 73 15 75 de 3b c4 67 c0 8f ca ad 31 f1 99│..s.u.;.g1..│

Signed-off-by: Anton Khirnov 

> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=78812cd147fa2ab1f0aa3019886c0abe00b7c63a
---

 libavcodec/h2645_parse.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 28db465059..9f66f079c2 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -40,8 +40,9 @@ int ff_h2645_extract_rbsp(const uint8_t *src, int length,
 
 nal->skipped_bytes = 0;
 #define STARTCODE_TEST  \
-if (i + 2 < length && src[i + 1] == 0 && src[i + 2] <= 3) { \
-if (src[i + 2] != 3 && src[i + 2] != 0) {   \
+if (i + 2 < length && src[i + 1] == 0 &&\
+   (src[i + 2] == 3 || src[i + 2] == 1)) {  \
+if (src[i + 2] == 1) {  \
 /* startcode, so we must be past the end */ \
 length = i; \
 }   \

___
ffmpeg-cvslog mailing list
ffmpeg-cvslog@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-cvslog

To unsubscribe, visit link above, or email
ffmpeg-cvslog-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2] avcodec/h2645_parse: Don't treat 0x000002 as a start code and truncate

2024-02-13 Thread Mattias Wadman

According to ITU-T H.265 7.4.2.1 this byte sequence should not appear in a
NAL unit but in practice in rare cases it seems it does, possibly due to buggy
encoders. Other players like VLC and Quicktime seem to be fine with it.

Currently when this sequence is found it is treated as if the next start code
has been found and the NAL unit gets truncated.

This change limits the code to only look for first start code 0x001 or
first escape 0x03.

Sadly i can't share the original source file with the issue but the first
80 bytes of the NAL unit looks like this:

   │00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f│0123456789abcdef│
0x0│00 00 00 01 02 01 d0 bc 57 a1 b8 44 70 01 00 0b│W..Dp...│
0x00010│80 2e 00 c2 6c ec 3e b9 e3 03 fb 91 2e d2 43 cb│l.>...C.│
0x00020│1d 2c 00 00 02 00 02 00 5c 93 72 6f 31 76 18 00│.,..\.ro1v..│
0x00030│08 38 aa b1 4c 33 3f fd 08 cb 77 9b d4 3c db 02│.8..L3?...w..<..│
0x00040│a2 04 73 15 75 de 3b c4 67 c0 8f ca ad 31 f1 99│..s.u.;.g1..│
---
 libavcodec/h2645_parse.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 28db465059..9f66f079c2 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -40,8 +40,9 @@ int ff_h2645_extract_rbsp(const uint8_t *src, int length,
 
 nal->skipped_bytes = 0;
 #define STARTCODE_TEST  \
-if (i + 2 < length && src[i + 1] == 0 && src[i + 2] <= 3) { \
-if (src[i + 2] != 3 && src[i + 2] != 0) {   \
+if (i + 2 < length && src[i + 1] == 0 &&\
+   (src[i + 2] == 3 || src[i + 2] == 1)) {  \
+if (src[i + 2] == 1) {  \
 /* startcode, so we must be past the end */ \
 length = i; \
 }   \
-- 
2.43.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v1] avcodec/h2645_parse: Don't treat 0x000002 as a start code and truncate

2024-02-12 Thread Mattias Wadman

According to ITU-T H.265 7.4.2.1 this byte sequence should not appear in a
NAL unit but in practice in rare cases it seems it does, possibly due to buggy
encoders. Other players like VLC and Quicktime seem to be fine with it.

Currently when this sequence is found it is treated as if the next start code
has been found and the NAL unit gets truncated.

This change limits the code to only look for first start code 0x001 or
first escape 0x03.

Sadly i can't share the original source file with the issue but the first
80 bytes of the NAL unit looks like this:

   │00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f│0123456789abcdef│
0x0│00 00 00 01 02 01 d0 bc 57 a1 b8 44 70 01 00 0b│W..Dp...│
0x00010│80 2e 00 c2 6c ec 3e b9 e3 03 fb 91 2e d2 43 cb│l.>...C.│
0x00020│1d 2c 00 00 02 00 02 00 5c 93 72 6f 31 76 18 00│.,..\.ro1v..│
0x00030│08 38 aa b1 4c 33 3f fd 08 cb 77 9b d4 3c db 02│.8..L3?...w..<..│
0x00040│a2 04 73 15 75 de 3b c4 67 c0 8f ca ad 31 f1 99│..s.u.;.g1..│
---
 libavcodec/h2645_parse.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 28db465059..d54bdd53c2 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -40,8 +40,9 @@ int ff_h2645_extract_rbsp(const uint8_t *src, int length,
 
 nal->skipped_bytes = 0;
 #define STARTCODE_TEST  \
-if (i + 2 < length && src[i + 1] == 0 && src[i + 2] <= 3) { \
-if (src[i + 2] != 3 && src[i + 2] != 0) {   \
+   if (i + 2 < length && src[i + 1] == 0 && \
+   (src[i + 2] == 3 || src[i + 2] == 1)) {  \
+if (src[i + 2] == 1) {  \
 /* startcode, so we must be past the end */ \
 length = i; \
 }   \
-- 
2.43.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Bug#1063457: nordugrid-arc and arcstat

2024-02-12 Thread Mattias Ellert

NorduGrid ARC has used the name arcstat since release 1.0. It has been
in Debian since January 2010 (source package nordugrid-arc-nox, later
renamed nordugrid-arc in May 2011).

The command is part of a set of commands, all using the arc prefix:
arccat arcget arckillarcproxy   arcresume  arcsync
arcclean   arcls  arcrename  arcrm  arctest
arccp  arched arcmkdir   arcrenew   arcstat
arcctl arcinfoarcplugin  arcresub   arcsub 

Mattias Ellert



signature.asc
Description: This is a digitally signed message part

Bug#1063457: nordugrid-arc and arcstat

2024-02-12 Thread Mattias Ellert

NorduGrid ARC has used the name arcstat since release 1.0. It has been
in Debian since January 2010 (source package nordugrid-arc-nox, later
renamed nordugrid-arc in May 2011).

The command is part of a set of commands, all using the arc prefix:
arccat arcget arckillarcproxy   arcresume  arcsync
arcclean   arcls  arcrename  arcrm  arctest
arccp  arched arcmkdir   arcrenew   arcstat
arcctl arcinfoarcplugin  arcresub   arcsub 

Mattias Ellert



signature.asc
Description: This is a digitally signed message part

[PATCH v7 5/5] vfio-user: Fix config space access byte order

PCI config space is little-endian, so on a big-endian host we need to
perform byte swaps for values as they are passed to and received from
the generic PCI config space access machinery.

Signed-off-by: Mattias Nissler 
---
 hw/remote/vfio-user-obj.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/remote/vfio-user-obj.c b/hw/remote/vfio-user-obj.c
index a15e291c9a..0e93d7a7b4 100644
--- a/hw/remote/vfio-user-obj.c
+++ b/hw/remote/vfio-user-obj.c
@@ -281,7 +281,7 @@ static ssize_t vfu_object_cfg_access(vfu_ctx_t *vfu_ctx, 
char * const buf,
 while (bytes > 0) {
 len = (bytes > pci_access_width) ? pci_access_width : bytes;
 if (is_write) {
-memcpy(, ptr, len);
+val = ldn_le_p(ptr, len);
 pci_host_config_write_common(o->pci_dev, offset,
  pci_config_size(o->pci_dev),
  val, len);
@@ -289,7 +289,7 @@ static ssize_t vfu_object_cfg_access(vfu_ctx_t *vfu_ctx, 
char * const buf,
 } else {
 val = pci_host_config_read_common(o->pci_dev, offset,
   pci_config_size(o->pci_dev), 
len);
-memcpy(ptr, , len);
+stn_le_p(ptr, len, val);
 trace_vfu_cfg_read(offset, val);
 }
 offset += len;
-- 
2.34.1

[PATCH v7 3/5] Update subprojects/libvfio-user

Brings in assorted bug fixes. The following are of particular interest
with respect to message-based DMA support:

* bb308a2 "Fix address calculation for message-based DMA"
  Corrects a bug in DMA address calculation.

* 1569a37 "Pass server->client command over a separate socket pair"
  Adds support for separate sockets for either command direction,
  addressing a bug where libvfio-user gets confused if both client and
  server send commands concurrently.

Signed-off-by: Mattias Nissler 
---
 subprojects/libvfio-user.wrap | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/subprojects/libvfio-user.wrap b/subprojects/libvfio-user.wrap
index 416955ca45..cdf0a7a375 100644
--- a/subprojects/libvfio-user.wrap
+++ b/subprojects/libvfio-user.wrap
@@ -1,4 +1,4 @@
 [wrap-git]
 url = https://gitlab.com/qemu-project/libvfio-user.git
-revision = 0b28d205572c80b568a1003db2c8f37ca333e4d7
+revision = 1569a37a54ecb63bd4008708c76339ccf7d06115
 depth = 1
-- 
2.34.1

Re: [PATCH v6 0/5] Support message-based DMA in vfio-user server

Hi Jonathan,

To the best of my knowledge, all patches in the series have been thoroughly
reviewed. Admittedly, I got a bit distracted with other things though, so
I've been dragging my feet on follow-through. Sorry about that.

I've just taken another look and found it no longer applies cleanly to
master due to a minor merge conflict. I've just sent a rebased version to
address that.

Stefan, are you OK to pick this up for merging at your next convenience?

Thanks,
Mattias



On Fri, Feb 9, 2024 at 6:39 PM Jonathan Cameron 
wrote:

> On Wed,  1 Nov 2023 06:16:06 -0700
> Mattias Nissler  wrote:
>
> > This series adds basic support for message-based DMA in qemu's vfio-user
> > server. This is useful for cases where the client does not provide file
> > descriptors for accessing system memory via memory mappings. My
> motivating use
> > case is to hook up device models as PCIe endpoints to a hardware design.
> This
> > works by bridging the PCIe transaction layer to vfio-user, and the
> endpoint
> > does not access memory directly, but sends memory requests TLPs to the
> hardware
> > design in order to perform DMA.
> >
> > Note that more work is needed to make message-based DMA work well: qemu
> > currently breaks down DMA accesses into chunks of size 8 bytes at
> maximum, each
> > of which will be handled in a separate vfio-user DMA request message.
> This is
> > quite terrible for large DMA accesses, such as when nvme reads and writes
> > page-sized blocks for example. Thus, I would like to improve qemu to be
> able to
> > perform larger accesses, at least for indirect memory regions. I have
> something
> > working locally, but since this will likely result in more involved
> surgery and
> > discussion, I am leaving this to be addressed in a separate patch.
> >
> Hi Mattias,
>
> I was wondering what the status of this patch set is - seems no
> outstanding issues
> have been raised?
>
> I'd run into a similar problem with multiple DMA mappings using the bounce
> buffer
> when using the emulated CXL memory with virtio-blk-pci accessing it.
>
> In that particular case virtio-blk is using the "memory" address space, but
> otherwise your first 2 patches work for me as well so I'd definitely like
> to see those get merged!
>
> Thanks,
>
> Jonathan
>
> > Changes from v1:
> >
> > * Address Stefan's review comments. In particular, enforce an allocation
> limit
> >   and don't drop the map client callbacks given that map requests can
> fail when
> >   hitting size limits.
> >
> > * libvfio-user version bump now included in the series.
> >
> > * Tested as well on big-endian s390x. This uncovered another byte order
> issue
> >   in vfio-user server code that I've included a fix for.
> >
> > Changes from v2:
> >
> > * Add a preparatory patch to make bounce buffering an
> AddressSpace-specific
> >   concept.
> >
> > * The total buffer size limit parameter is now per AdressSpace and can be
> >   configured for PCIDevice via a property.
> >
> > * Store a magic value in first bytes of bounce buffer struct as a best
> effort
> >   measure to detect invalid pointers in address_space_unmap.
> >
> > Changes from v3:
> >
> > * libvfio-user now supports twin-socket mode which uses separate sockets
> for
> >   client->server and server->client commands, respectively. This
> addresses the
> >   concurrent command bug triggered by server->client DMA access
> commands. See
> >   https://github.com/nutanix/libvfio-user/issues/279 for details.
> >
> > * Add missing teardown code in do_address_space_destroy.
> >
> > * Fix bounce buffer size bookkeeping race condition.
> >
> > * Generate unmap notification callbacks unconditionally.
> >
> > * Some cosmetic fixes.
> >
> > Changes from v4:
> >
> > * Fix accidentally dropped memory_region_unref, control flow restored to
> match
> >   previous code to simplify review.
> >
> > * Some cosmetic fixes.
> >
> > Changes from v5:
> >
> > * Unregister indirect memory region in libvfio-user dma_unregister
> callback.
> >
> > I believe all patches in the series have been reviewed appropriately, so
> my
> > hope is that this will be the final iteration. Stefan, Peter, Jag,
> thanks for
> > your feedback, let me know if there's anything else needed from my side
> before
> > this can get merged.
> >
> > Mattias Nissler (5):
> >   softmmu: Per-AddressSpace bounce buffering
> >   softmmu: Support concurrent bounce buff

[PATCH v7 1/5] softmmu: Per-AddressSpace bounce buffering

Instead of using a single global bounce buffer, give each AddressSpace
its own bounce buffer. The MapClient callback mechanism moves to
AddressSpace accordingly.

This is in preparation for generalizing bounce buffer handling further
to allow multiple bounce buffers, with a total allocation limit
configured per AddressSpace.

Signed-off-by: Mattias Nissler 
---
 include/exec/cpu-common.h |   2 -
 include/exec/memory.h |  45 -
 system/dma-helpers.c  |   4 +-
 system/memory.c   |   7 +++
 system/physmem.c  | 101 --
 5 files changed, 93 insertions(+), 66 deletions(-)

diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index 9ead1be100..bd6999fa35 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -148,8 +148,6 @@ void *cpu_physical_memory_map(hwaddr addr,
   bool is_write);
 void cpu_physical_memory_unmap(void *buffer, hwaddr len,
bool is_write, hwaddr access_len);
-void cpu_register_map_client(QEMUBH *bh);
-void cpu_unregister_map_client(QEMUBH *bh);
 
 bool cpu_physical_memory_is_io(hwaddr phys_addr);
 
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 177be23db7..6995a443d3 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -1106,6 +1106,19 @@ struct MemoryListener {
 QTAILQ_ENTRY(MemoryListener) link_as;
 };
 
+typedef struct AddressSpaceMapClient {
+QEMUBH *bh;
+QLIST_ENTRY(AddressSpaceMapClient) link;
+} AddressSpaceMapClient;
+
+typedef struct {
+MemoryRegion *mr;
+void *buffer;
+hwaddr addr;
+hwaddr len;
+bool in_use;
+} BounceBuffer;
+
 /**
  * struct AddressSpace: describes a mapping of addresses to #MemoryRegion 
objects
  */
@@ -1123,6 +1136,12 @@ struct AddressSpace {
 struct MemoryRegionIoeventfd *ioeventfds;
 QTAILQ_HEAD(, MemoryListener) listeners;
 QTAILQ_ENTRY(AddressSpace) address_spaces_link;
+
+/* Bounce buffer to use for this address space. */
+BounceBuffer bounce;
+/* List of callbacks to invoke when buffers free up */
+QemuMutex map_client_list_lock;
+QLIST_HEAD(, AddressSpaceMapClient) map_client_list;
 };
 
 typedef struct AddressSpaceDispatch AddressSpaceDispatch;
@@ -2926,8 +2945,8 @@ bool address_space_access_valid(AddressSpace *as, hwaddr 
addr, hwaddr len,
  * May return %NULL and set *@plen to zero(0), if resources needed to perform
  * the mapping are exhausted.
  * Use only for reads OR writes - not for read-modify-write operations.
- * Use cpu_register_map_client() to know when retrying the map operation is
- * likely to succeed.
+ * Use address_space_register_map_client() to know when retrying the map
+ * operation is likely to succeed.
  *
  * @as: #AddressSpace to be accessed
  * @addr: address within that address space
@@ -2952,6 +2971,28 @@ void *address_space_map(AddressSpace *as, hwaddr addr,
 void address_space_unmap(AddressSpace *as, void *buffer, hwaddr len,
  bool is_write, hwaddr access_len);
 
+/*
+ * address_space_register_map_client: Register a callback to invoke when
+ * resources for address_space_map() are available again.
+ *
+ * address_space_map may fail when there are not enough resources available,
+ * such as when bounce buffer memory would exceed the limit. The callback can
+ * be used to retry the address_space_map operation. Note that the callback
+ * gets automatically removed after firing.
+ *
+ * @as: #AddressSpace to be accessed
+ * @bh: callback to invoke when address_space_map() retry is appropriate
+ */
+void address_space_register_map_client(AddressSpace *as, QEMUBH *bh);
+
+/*
+ * address_space_unregister_map_client: Unregister a callback that has
+ * previously been registered and not fired yet.
+ *
+ * @as: #AddressSpace to be accessed
+ * @bh: callback to unregister
+ */
+void address_space_unregister_map_client(AddressSpace *as, QEMUBH *bh);
 
 /* Internal functions, part of the implementation of address_space_read.  */
 MemTxResult address_space_read_full(AddressSpace *as, hwaddr addr,
diff --git a/system/dma-helpers.c b/system/dma-helpers.c
index 9b221cf94e..74013308f5 100644
--- a/system/dma-helpers.c
+++ b/system/dma-helpers.c
@@ -169,7 +169,7 @@ static void dma_blk_cb(void *opaque, int ret)
 if (dbs->iov.size == 0) {
 trace_dma_map_wait(dbs);
 dbs->bh = aio_bh_new(ctx, reschedule_dma, dbs);
-cpu_register_map_client(dbs->bh);
+address_space_register_map_client(dbs->sg->as, dbs->bh);
 return;
 }
 
@@ -197,7 +197,7 @@ static void dma_aio_cancel(BlockAIOCB *acb)
 }
 
 if (dbs->bh) {
-cpu_unregister_map_client(dbs->bh);
+address_space_unregister_map_client(dbs->sg->as, dbs->bh);
 qemu_bh_delete(dbs->bh);
 dbs->bh = NULL;
 }
diff --git a/system/memory.c b/system/memory.c
index a229a79988..ad0caef1b8 100644
---

[PATCH v7 2/5] softmmu: Support concurrent bounce buffers

When DMA memory can't be directly accessed, as is the case when
running the device model in a separate process without shareable DMA
file descriptors, bounce buffering is used.

It is not uncommon for device models to request mapping of several DMA
regions at the same time. Examples include:
 * net devices, e.g. when transmitting a packet that is split across
   several TX descriptors (observed with igb)
 * USB host controllers, when handling a packet with multiple data TRBs
   (observed with xhci)

Previously, qemu only provided a single bounce buffer per AddressSpace
and would fail DMA map requests while the buffer was already in use. In
turn, this would cause DMA failures that ultimately manifest as hardware
errors from the guest perspective.

This change allocates DMA bounce buffers dynamically instead of
supporting only a single buffer. Thus, multiple DMA mappings work
correctly also when RAM can't be mmap()-ed.

The total bounce buffer allocation size is limited individually for each
AddressSpace. The default limit is 4096 bytes, matching the previous
maximum buffer size. A new x-max-bounce-buffer-size parameter is
provided to configure the limit for PCI devices.

Signed-off-by: Mattias Nissler 
---
 hw/pci/pci.c|  8 
 include/exec/memory.h   | 14 +++
 include/hw/pci/pci_device.h |  3 ++
 system/memory.c |  5 ++-
 system/physmem.c| 80 +
 5 files changed, 74 insertions(+), 36 deletions(-)

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 6496d027ca..036b3ff822 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -85,6 +85,8 @@ static Property pci_props[] = {
 QEMU_PCIE_ERR_UNC_MASK_BITNR, true),
 DEFINE_PROP_BIT("x-pcie-ari-nextfn-1", PCIDevice, cap_present,
 QEMU_PCIE_ARI_NEXTFN_1_BITNR, false),
+DEFINE_PROP_SIZE("x-max-bounce-buffer-size", PCIDevice,
+ max_bounce_buffer_size, DEFAULT_MAX_BOUNCE_BUFFER_SIZE),
 DEFINE_PROP_END_OF_LIST()
 };
 
@@ -1203,6 +1205,8 @@ static PCIDevice *do_pci_register_device(PCIDevice 
*pci_dev,
"bus master container", UINT64_MAX);
 address_space_init(_dev->bus_master_as,
_dev->bus_master_container_region, pci_dev->name);
+pci_dev->bus_master_as.max_bounce_buffer_size =
+pci_dev->max_bounce_buffer_size;
 
 if (phase_check(PHASE_MACHINE_READY)) {
 pci_init_bus_master(pci_dev);
@@ -2632,6 +2636,10 @@ static void pci_device_class_init(ObjectClass *klass, 
void *data)
 k->unrealize = pci_qdev_unrealize;
 k->bus_type = TYPE_PCI_BUS;
 device_class_set_props(k, pci_props);
+object_class_property_set_description(
+klass, "x-max-bounce-buffer-size",
+"Maximum buffer size allocated for bounce buffers used for mapped "
+"access to indirect DMA memory");
 }
 
 static void pci_device_class_base_init(ObjectClass *klass, void *data)
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 6995a443d3..e7bc4717ea 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -,13 +,7 @@ typedef struct AddressSpaceMapClient {
 QLIST_ENTRY(AddressSpaceMapClient) link;
 } AddressSpaceMapClient;
 
-typedef struct {
-MemoryRegion *mr;
-void *buffer;
-hwaddr addr;
-hwaddr len;
-bool in_use;
-} BounceBuffer;
+#define DEFAULT_MAX_BOUNCE_BUFFER_SIZE (4096)
 
 /**
  * struct AddressSpace: describes a mapping of addresses to #MemoryRegion 
objects
@@ -1137,8 +1131,10 @@ struct AddressSpace {
 QTAILQ_HEAD(, MemoryListener) listeners;
 QTAILQ_ENTRY(AddressSpace) address_spaces_link;
 
-/* Bounce buffer to use for this address space. */
-BounceBuffer bounce;
+/* Maximum DMA bounce buffer size used for indirect memory map requests */
+uint64_t max_bounce_buffer_size;
+/* Total size of bounce buffers currently allocated, atomically accessed */
+uint64_t bounce_buffer_size;
 /* List of callbacks to invoke when buffers free up */
 QemuMutex map_client_list_lock;
 QLIST_HEAD(, AddressSpaceMapClient) map_client_list;
diff --git a/include/hw/pci/pci_device.h b/include/hw/pci/pci_device.h
index d3dd0f64b2..f4027c5379 100644
--- a/include/hw/pci/pci_device.h
+++ b/include/hw/pci/pci_device.h
@@ -160,6 +160,9 @@ struct PCIDevice {
 /* ID of standby device in net_failover pair */
 char *failover_pair_id;
 uint32_t acpi_index;
+
+/* Maximum DMA bounce buffer size used for indirect memory map requests */
+uint64_t max_bounce_buffer_size;
 };
 
 static inline int pci_intx(PCIDevice *pci_dev)
diff --git a/system/memory.c b/system/memory.c
index ad0caef1b8..1cf89654a1 100644
--- a/system/memory.c
+++ b/system/memory.c
@@ -3133,7 +3133,8 @@ void address_space_init(AddressSpace *as, MemoryRegion 
*root, const char *name)
 as->ioeventfds = NULL;

[PATCH v7 4/5] vfio-user: Message-based DMA support

Wire up support for DMA for the case where the vfio-user client does not
provide mmap()-able file descriptors, but DMA requests must be performed
via the VFIO-user protocol. This installs an indirect memory region,
which already works for pci_dma_{read,write}, and pci_dma_map works
thanks to the existing DMA bounce buffering support.

Note that while simple scenarios work with this patch, there's a known
race condition in libvfio-user that will mess up the communication
channel. See https://github.com/nutanix/libvfio-user/issues/279 for
details as well as a proposed fix.

Signed-off-by: Mattias Nissler 
---
 hw/remote/trace-events|   2 +
 hw/remote/vfio-user-obj.c | 100 --
 2 files changed, 87 insertions(+), 15 deletions(-)

diff --git a/hw/remote/trace-events b/hw/remote/trace-events
index 0d1b7d56a5..358a68fb34 100644
--- a/hw/remote/trace-events
+++ b/hw/remote/trace-events
@@ -9,6 +9,8 @@ vfu_cfg_read(uint32_t offset, uint32_t val) "vfu: cfg: 0x%x -> 
0x%x"
 vfu_cfg_write(uint32_t offset, uint32_t val) "vfu: cfg: 0x%x <- 0x%x"
 vfu_dma_register(uint64_t gpa, size_t len) "vfu: registering GPA 0x%"PRIx64", 
%zu bytes"
 vfu_dma_unregister(uint64_t gpa) "vfu: unregistering GPA 0x%"PRIx64""
+vfu_dma_read(uint64_t gpa, size_t len) "vfu: DMA read 0x%"PRIx64", %zu bytes"
+vfu_dma_write(uint64_t gpa, size_t len) "vfu: DMA write 0x%"PRIx64", %zu bytes"
 vfu_bar_register(int i, uint64_t addr, uint64_t size) "vfu: BAR %d: addr 
0x%"PRIx64" size 0x%"PRIx64""
 vfu_bar_rw_enter(const char *op, uint64_t addr) "vfu: %s request for BAR 
address 0x%"PRIx64""
 vfu_bar_rw_exit(const char *op, uint64_t addr) "vfu: Finished %s of BAR 
address 0x%"PRIx64""
diff --git a/hw/remote/vfio-user-obj.c b/hw/remote/vfio-user-obj.c
index d9b879e056..a15e291c9a 100644
--- a/hw/remote/vfio-user-obj.c
+++ b/hw/remote/vfio-user-obj.c
@@ -300,6 +300,63 @@ static ssize_t vfu_object_cfg_access(vfu_ctx_t *vfu_ctx, 
char * const buf,
 return count;
 }
 
+static MemTxResult vfu_dma_read(void *opaque, hwaddr addr, uint64_t *val,
+unsigned size, MemTxAttrs attrs)
+{
+MemoryRegion *region = opaque;
+vfu_ctx_t *vfu_ctx = VFU_OBJECT(region->owner)->vfu_ctx;
+uint8_t buf[sizeof(uint64_t)];
+
+trace_vfu_dma_read(region->addr + addr, size);
+
+g_autofree dma_sg_t *sg = g_malloc0(dma_sg_size());
+vfu_dma_addr_t vfu_addr = (vfu_dma_addr_t)(region->addr + addr);
+if (vfu_addr_to_sgl(vfu_ctx, vfu_addr, size, sg, 1, PROT_READ) < 0 ||
+vfu_sgl_read(vfu_ctx, sg, 1, buf) != 0) {
+return MEMTX_ERROR;
+}
+
+*val = ldn_he_p(buf, size);
+
+return MEMTX_OK;
+}
+
+static MemTxResult vfu_dma_write(void *opaque, hwaddr addr, uint64_t val,
+ unsigned size, MemTxAttrs attrs)
+{
+MemoryRegion *region = opaque;
+vfu_ctx_t *vfu_ctx = VFU_OBJECT(region->owner)->vfu_ctx;
+uint8_t buf[sizeof(uint64_t)];
+
+trace_vfu_dma_write(region->addr + addr, size);
+
+stn_he_p(buf, size, val);
+
+g_autofree dma_sg_t *sg = g_malloc0(dma_sg_size());
+vfu_dma_addr_t vfu_addr = (vfu_dma_addr_t)(region->addr + addr);
+if (vfu_addr_to_sgl(vfu_ctx, vfu_addr, size, sg, 1, PROT_WRITE) < 0 ||
+vfu_sgl_write(vfu_ctx, sg, 1, buf) != 0) {
+return MEMTX_ERROR;
+}
+
+return MEMTX_OK;
+}
+
+static const MemoryRegionOps vfu_dma_ops = {
+.read_with_attrs = vfu_dma_read,
+.write_with_attrs = vfu_dma_write,
+.endianness = DEVICE_HOST_ENDIAN,
+.valid = {
+.min_access_size = 1,
+.max_access_size = 8,
+.unaligned = true,
+},
+.impl = {
+.min_access_size = 1,
+.max_access_size = 8,
+},
+};
+
 static void dma_register(vfu_ctx_t *vfu_ctx, vfu_dma_info_t *info)
 {
 VfuObject *o = vfu_get_private(vfu_ctx);
@@ -308,17 +365,30 @@ static void dma_register(vfu_ctx_t *vfu_ctx, 
vfu_dma_info_t *info)
 g_autofree char *name = NULL;
 struct iovec *iov = >iova;
 
-if (!info->vaddr) {
-return;
-}
-
 name = g_strdup_printf("mem-%s-%"PRIx64"", o->device,
-   (uint64_t)info->vaddr);
+   (uint64_t)iov->iov_base);
 
 subregion = g_new0(MemoryRegion, 1);
 
-memory_region_init_ram_ptr(subregion, NULL, name,
-   iov->iov_len, info->vaddr);
+if (info->vaddr) {
+memory_region_init_ram_ptr(subregion, OBJECT(o), name,
+   iov->iov_len, info->vaddr);
+} else {
+/*
+ * Note that I/O regions' MemoryRegionOps handle accesses of at most 8
+ * bytes at a time, and larger accesses are broken down. However,
+

[PATCH v7 0/5] Support message-based DMA in vfio-user server

This series adds basic support for message-based DMA in qemu's vfio-user
server. This is useful for cases where the client does not provide file
descriptors for accessing system memory via memory mappings. My motivating use
case is to hook up device models as PCIe endpoints to a hardware design. This
works by bridging the PCIe transaction layer to vfio-user, and the endpoint
does not access memory directly, but sends memory requests TLPs to the hardware
design in order to perform DMA.

Note that more work is needed to make message-based DMA work well: qemu
currently breaks down DMA accesses into chunks of size 8 bytes at maximum, each
of which will be handled in a separate vfio-user DMA request message. This is
quite terrible for large DMA accesses, such as when nvme reads and writes
page-sized blocks for example. Thus, I would like to improve qemu to be able to
perform larger accesses, at least for indirect memory regions. I have something
working locally, but since this will likely result in more involved surgery and
discussion, I am leaving this to be addressed in a separate patch.

Changes from v1:

* Address Stefan's review comments. In particular, enforce an allocation limit
  and don't drop the map client callbacks given that map requests can fail when
  hitting size limits.

* libvfio-user version bump now included in the series.

* Tested as well on big-endian s390x. This uncovered another byte order issue
  in vfio-user server code that I've included a fix for.

Changes from v2:

* Add a preparatory patch to make bounce buffering an AddressSpace-specific
  concept.

* The total buffer size limit parameter is now per AdressSpace and can be
  configured for PCIDevice via a property.

* Store a magic value in first bytes of bounce buffer struct as a best effort
  measure to detect invalid pointers in address_space_unmap.

Changes from v3:

* libvfio-user now supports twin-socket mode which uses separate sockets for
  client->server and server->client commands, respectively. This addresses the
  concurrent command bug triggered by server->client DMA access commands. See
  https://github.com/nutanix/libvfio-user/issues/279 for details.

* Add missing teardown code in do_address_space_destroy.

* Fix bounce buffer size bookkeeping race condition.

* Generate unmap notification callbacks unconditionally.

* Some cosmetic fixes.

Changes from v4:

* Fix accidentally dropped memory_region_unref, control flow restored to match
  previous code to simplify review.

* Some cosmetic fixes.

Changes from v5:

* Unregister indirect memory region in libvfio-user dma_unregister callback.

Changes from v6:

* Rebase, resolve straightforward merge conflict in system/dma-helpers.c

Mattias Nissler (5):
  softmmu: Per-AddressSpace bounce buffering
  softmmu: Support concurrent bounce buffers
  Update subprojects/libvfio-user
  vfio-user: Message-based DMA support
  vfio-user: Fix config space access byte order

 hw/pci/pci.c  |   8 ++
 hw/remote/trace-events|   2 +
 hw/remote/vfio-user-obj.c | 104 +
 include/exec/cpu-common.h |   2 -
 include/exec/memory.h |  41 +-
 include/hw/pci/pci_device.h   |   3 +
 subprojects/libvfio-user.wrap |   2 +-
 system/dma-helpers.c  |   4 +-
 system/memory.c   |   8 ++
 system/physmem.c  | 141 ++
 10 files changed, 226 insertions(+), 89 deletions(-)

-- 
2.34.1

Bug#1062167: globus-rsl: NMU diff for 64-bit time_t transition

Package updated in unstable:

Date: Fri, 09 Feb 2024 14:32:37 +0100
Source: globus-rsl
Architecture: source
Version: 11.4-1
Distribution: unstable



signature.asc
Description: This is a digitally signed message part

Bug#1063156: myproxy: NMU diff for 64-bit time_t transition

Package updated in unstable:

Date: Fri, 09 Feb 2024 14:44:42 +0100
Source: myproxy
Architecture: source
Version: 6.2.16-1
Distribution: unstable



signature.asc
Description: This is a digitally signed message part

Bug#1062157: globus-gsi-credential: NMU diff for 64-bit time_t transition

Package updated in unstable:

Date: Fri, 09 Feb 2024 14:19:40 +0100
Source: globus-gsi-credential
Architecture: source
Version: 8.4-1
Distribution: unstable



signature.asc
Description: This is a digitally signed message part

Bug#1062156: globus-gsi-cert-utils: NMU diff for 64-bit time_t transition

Package updated in unstable:

Date: Fri, 09 Feb 2024 14:04:34 +0100
Source: globus-gsi-cert-utils
Architecture: source
Version: 10.11-1
Distribution: unstable



signature.asc
Description: This is a digitally signed message part

Bug#1062160: globus-gsi-sysconfig: NMU diff for 64-bit time_t transition

Package updated in unstable:

Date: Fri, 09 Feb 2024 15:12:34 +0100
Source: globus-gsi-sysconfig
Architecture: source
Version: 9.6-1
Distribution: unstable



signature.asc
Description: This is a digitally signed message part

Bug#1062153: globus-gridftp-server: NMU diff for 64-bit time_t transition

Package updated in unstable:

Date: Fri, 09 Feb 2024 13:48:21 +0100
Source: globus-gridftp-server
Architecture: source
Version: 13.25-1
Distribution: unstable



signature.asc
Description: This is a digitally signed message part

Bug#1062145: globus-gass-copy: NMU diff for 64-bit time_t transition

Package updated in unstable:

Date: Fri, 09 Feb 2024 12:34:54 +0100
Source: globus-gass-copy
Architecture: source
Version: 10.13-1
Distribution: unstable



signature.asc
Description: This is a digitally signed message part

Bug#1062141: globus-common: NMU diff for 64-bit time_t transition

Package updated in unstable:

Date: Fri, 09 Feb 2024 11:13:35 +0100
Source: globus-common
Architecture: source
Version: 18.14-1
Distribution: unstable



signature.asc
Description: This is a digitally signed message part

Bug#1063298: xrootd: NMU diff for 64-bit time_t transition

2024-02-08 Thread Mattias Ellert

The package was updated in unstable

xrootd 5.6.7-1

If/when you update the package in experimental for the transition,
please include the missing change in debian/rules mentioned in a
previous comment to this bug.



signature.asc
Description: This is a digitally signed message part

Bug#1063204: nordugrid-arc: NMU diff for 64-bit time_t transition

2024-02-08 Thread Mattias Ellert

The package was updated in unstable.

nordugrid-arc 6.18.0-2



signature.asc
Description: This is a digitally signed message part

Bug#1036884: Schedule

Hi!

The earliest of the RC bugs filed for this transition have now been
unresolved long enough to trigger AUTORM threats.

This is unfortunate, since the maintainers can't do anything to fix
them, since they are un-fixable until the required changes to the
default compiler flags are implemented.

In order for threats of removal not to trigger maintainers to blindly
applying the proposed patches and uploading to unstable to close the
bugs, you should either start the transition now or downgrade the
severity of the bugs.

Personally I think it would have made more sense to file these bugs
with minor or normal severity (since they are simply informational at
this stage) and then upgrade them to serious when the transition starts
(at which point they become RC).

Do you have an estimate when the uploads to unstable will start?

Mattias



signature.asc
Description: This is a digitally signed message part

Bug#1036884: Schedule

Hi!

The earliest of the RC bugs filed for this transition have now been
unresolved long enough to trigger AUTORM threats.

This is unfortunate, since the maintainers can't do anything to fix
them, since they are un-fixable until the required changes to the
default compiler flags are implemented.

In order for threats of removal not to trigger maintainers to blindly
applying the proposed patches and uploading to unstable to close the
bugs, you should either start the transition now or downgrade the
severity of the bugs.

Personally I think it would have made more sense to file these bugs
with minor or normal severity (since they are simply informational at
this stage) and then upgrade them to serious when the transition starts
(at which point they become RC).

Do you have an estimate when the uploads to unstable will start?

Mattias



signature.asc
Description: This is a digitally signed message part

Bug#1063298: xrootd: NMU diff for 64-bit time_t transition

Hi!

The proposed change is incomplete, and the build failed on some
architectures.

You need to update debian/rules due to the changes package names:

Line 31 must change from

N = -Nlibxrdec1

to

N = -Nlibxrdec1t64

Regards,

Mattias (package maintainer)



signature.asc
Description: This is a digitally signed message part

Bug#1063298: xrootd: NMU diff for 64-bit time_t transition