On 03/04/2012 05:59 PM, Michael S. Tsirkin wrote:
On Fri, Mar 02, 2012 at 07:02:21AM -0500, Stefan Berger wrote:
Having instrumented the code with qemu_mutex_trylock() and a counter
for failed attempts with subsequent qemu_mutex_lock() practically
shows no lock contention at all for either polli
Resending with people properly cc'ed.
On 03/04/2012 05:59 PM, Michael S. Tsirkin wrote:
On Fri, Mar 02, 2012 at 07:02:21AM -0500, Stefan Berger wrote:
Having instrumented the code with qemu_mutex_trylock() and a counter
for failed attempts with subsequent qemu_mutex_lock() practically
shows no
On Fri, Mar 02, 2012 at 07:02:21AM -0500, Stefan Berger wrote:
> On 02/21/2012 06:08 PM, Michael S. Tsirkin wrote:
> >On Tue, Feb 21, 2012 at 05:30:32PM -0500, Stefan Berger wrote:
> >>On 02/21/2012 02:58 PM, Michael S. Tsirkin wrote:
> >>>On Tue, Feb 21, 2012 at 10:05:26AM -0500, Stefan Berger wro
On 02/21/2012 06:08 PM, Michael S. Tsirkin wrote:
On Tue, Feb 21, 2012 at 05:30:32PM -0500, Stefan Berger wrote:
On 02/21/2012 02:58 PM, Michael S. Tsirkin wrote:
On Tue, Feb 21, 2012 at 10:05:26AM -0500, Stefan Berger wrote:
On 02/21/2012 07:18 AM, Michael S. Tsirkin wrote:
When the backend d
On 02/20/2012 10:48 AM, Stefan Berger wrote:
On 02/20/2012 03:51 AM, Michael S. Tsirkin wrote:
+static const MemoryRegionOps tpm_tis_memory_ops = {
+.read = tpm_tis_mmio_read,
+.write = tpm_tis_mmio_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
Are you sure? Most devices are BIG or
On 02/21/2012 06:08 PM, Michael S. Tsirkin wrote:
On Tue, Feb 21, 2012 at 05:30:32PM -0500, Stefan Berger wrote:
On 02/21/2012 02:58 PM, Michael S. Tsirkin wrote:
Worst case, you can take a qemu mutex. Is tpm very
performance-sensitive to make contention on that
lock a problem?
FYI: Some pe
On 02/21/2012 11:34 PM, Michael S. Tsirkin wrote:
On Tue, Feb 21, 2012 at 07:21:28PM -0500, Stefan Berger wrote:
On 02/21/2012 06:08 PM, Michael S. Tsirkin wrote:
The locking times are short since no major computations
are done while the lock is held.
Considering that the TPM TIS interface i
On Tue, Feb 21, 2012 at 07:21:28PM -0500, Stefan Berger wrote:
> On 02/21/2012 06:08 PM, Michael S. Tsirkin wrote:
> >On Tue, Feb 21, 2012 at 05:30:32PM -0500, Stefan Berger wrote:
> >
> >
> >>At the moment there are two backends that need threading: the
> >>libtpms and passthrough backends. Both w
On 02/21/2012 06:08 PM, Michael S. Tsirkin wrote:
On Tue, Feb 21, 2012 at 05:30:32PM -0500, Stefan Berger wrote:
At the moment there are two backends that need threading: the
libtpms and passthrough backends. Both will require locking of
datastructures that belong to the frontend. Only the nul
On Tue, Feb 21, 2012 at 05:30:32PM -0500, Stefan Berger wrote:
> On 02/21/2012 02:58 PM, Michael S. Tsirkin wrote:
> >On Tue, Feb 21, 2012 at 10:05:26AM -0500, Stefan Berger wrote:
> >>On 02/21/2012 07:18 AM, Michael S. Tsirkin wrote:
> >>>
> >>When the backend delivers the response it checks wheth
On 02/21/2012 02:58 PM, Michael S. Tsirkin wrote:
On Tue, Feb 21, 2012 at 10:05:26AM -0500, Stefan Berger wrote:
On 02/21/2012 07:18 AM, Michael S. Tsirkin wrote:
When the backend delivers the response it checks whether the
interface is used in interrupt mode and raises the interrupt.
IMO it
On Tue, Feb 21, 2012 at 10:05:26AM -0500, Stefan Berger wrote:
> On 02/21/2012 07:18 AM, Michael S. Tsirkin wrote:
> >On Tue, Feb 21, 2012 at 06:19:26AM -0500, Stefan Berger wrote:
> >>On 02/20/2012 10:18 PM, Michael S. Tsirkin wrote:
> >>>On Mon, Feb 20, 2012 at 07:43:05PM -0500, Stefan Berger wro
On 02/21/2012 07:18 AM, Michael S. Tsirkin wrote:
On Tue, Feb 21, 2012 at 06:19:26AM -0500, Stefan Berger wrote:
On 02/20/2012 10:18 PM, Michael S. Tsirkin wrote:
On Mon, Feb 20, 2012 at 07:43:05PM -0500, Stefan Berger wrote:
On 02/20/2012 05:02 PM, Michael S. Tsirkin wrote:
On Wed, Dec 14, 2
On Tue, Feb 21, 2012 at 06:19:26AM -0500, Stefan Berger wrote:
> On 02/20/2012 10:18 PM, Michael S. Tsirkin wrote:
> >On Mon, Feb 20, 2012 at 07:43:05PM -0500, Stefan Berger wrote:
> >>On 02/20/2012 05:02 PM, Michael S. Tsirkin wrote:
> >>>On Wed, Dec 14, 2011 at 08:43:17AM -0500, Stefan Berger wro
On 02/20/2012 10:18 PM, Michael S. Tsirkin wrote:
On Mon, Feb 20, 2012 at 07:43:05PM -0500, Stefan Berger wrote:
On 02/20/2012 05:02 PM, Michael S. Tsirkin wrote:
On Wed, Dec 14, 2011 at 08:43:17AM -0500, Stefan Berger wrote:
+/*
+ * Send a TPM request.
+ * Call this with the state_lock held s
On Mon, Feb 20, 2012 at 07:43:05PM -0500, Stefan Berger wrote:
> On 02/20/2012 05:02 PM, Michael S. Tsirkin wrote:
> >On Wed, Dec 14, 2011 at 08:43:17AM -0500, Stefan Berger wrote:
> >>+/*
> >>+ * Send a TPM request.
> >>+ * Call this with the state_lock held so we can sync with the receive
> >>+ *
On 02/20/2012 05:02 PM, Michael S. Tsirkin wrote:
On Wed, Dec 14, 2011 at 08:43:17AM -0500, Stefan Berger wrote:
+/*
+ * Send a TPM request.
+ * Call this with the state_lock held so we can sync with the receive
+ * callback.
+ */
+static void tpm_tis_tpm_send(TPMState *s, uint8_t locty)
+{
+
On Wed, Dec 14, 2011 at 08:43:17AM -0500, Stefan Berger wrote:
> +/*
> + * Send a TPM request.
> + * Call this with the state_lock held so we can sync with the receive
> + * callback.
> + */
> +static void tpm_tis_tpm_send(TPMState *s, uint8_t locty)
> +{
> +TPMTISState *tis = &s->s.tis;
> +
>
On 02/20/2012 02:37 PM, Michael S. Tsirkin wrote:
On Mon, Feb 20, 2012 at 10:48:09AM -0500, Stefan Berger wrote:
On 02/20/2012 03:51 AM, Michael S. Tsirkin wrote:
On Wed, Dec 14, 2011 at 08:43:17AM -0500, Stefan Berger wrote:
Yes, but that's ok. We are only registering the MMIO region [fed4
0
On Mon, Feb 20, 2012 at 10:48:09AM -0500, Stefan Berger wrote:
> On 02/20/2012 03:51 AM, Michael S. Tsirkin wrote:
> >On Wed, Dec 14, 2011 at 08:43:17AM -0500, Stefan Berger wrote:
> >>This patch adds the main code of the TPM frontend driver, the TPM TIS
> >>interface, to Qemu. The code is largely
On 02/20/2012 03:51 AM, Michael S. Tsirkin wrote:
On Wed, Dec 14, 2011 at 08:43:17AM -0500, Stefan Berger wrote:
This patch adds the main code of the TPM frontend driver, the TPM TIS
interface, to Qemu. The code is largely based on the previous implementation
for Xen but has been significantly e
On Wed, Dec 14, 2011 at 08:43:17AM -0500, Stefan Berger wrote:
> This patch adds the main code of the TPM frontend driver, the TPM TIS
> interface, to Qemu. The code is largely based on the previous implementation
> for Xen but has been significantly extended to meet the standard's
> requirements,
This patch adds the main code of the TPM frontend driver, the TPM TIS
interface, to Qemu. The code is largely based on the previous implementation
for Xen but has been significantly extended to meet the standard's
requirements, such as the support for changing of localities and all the
functionalit
23 matches
Mail list logo
